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PREFACE 



This manual describes the operation, control, and monitoring functions 
of TOPS-10 DECnet-10 Version 4.0 and PSI Version 1,0. It includes 
both tutorial and reference information. 

The audience addressed is: 

o The DECnet-10/PSI-10 System Manager 

o The user with local or remote system privileges who is 
engaged in network management and operational tasks under the 
direction of the system manager 

This manual assumes that its readers are experienced in TOPS-10 
operations and familiar with computer networks. Previous experience 
with DECnet is not assumed. However, if you have not yet read the 
manual. Introduction to DECnet , do so before continuing with this 
manual. 

MANUAL ORGANIZATION 

This manual contains two parts as follows: 

PART I, INTRODUCTION, contains two chapters. 

Chapter 1, SYSTEM OVERVIEW, briefly describes the DIGITAL Network 
Architecture (DNA) that is the model used to design networks of 
DIGITAL computers. This chapter emphasizes the relationships 
between the Network Management Layer (NML) and other functional 
layers, and describes the DECnet-10 implementation of DNA, 

Chapter 2, NETWORK CONCEPTS, defines the basic network concepts 
in relation to the operation of the DECnet-10 network. 

PART II, DECnet OPERATION, contains six chapters. 

Chapter 3, RUNNING DECnet-10, includes the minimum information 
needed by operators responsible for keeping the network up and 
running. This chapter explains procedures and gives examples for 
such tasks as manual loading of the DN20 front end, controlling 
line states, monitoring the network, recognizing potential 
problems, and running the PAL program. 

Chapter 4, THE NETWORK CONTROL PROGRAM, is a tutorial on NCP, the 
control language that is the operator's and manager's interface 
to the network control program, NML. 

Chapter 5, NCP COMMANDS PROCESSED BY OPR, describes the syntax 
and function of NCP commands processed by OPR. 
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Chapter 6, NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM, 
describes the syntax and function of NCP commands processed by 
the local node* s NML, 

Chapter 7, NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT 
LAYER, describes the syntax and function of NCP commands 
processed by the local node' s NML and the remote node' s Network 
Management Program. 

Chapter 8, NETWORK MANAGEMENT PACKET SWITCHING INTERFACE, 

describes X.25 NCP commands for using Public Packet Switching 

Networks (PPSNs) as part of the Packetnet System Interface (PSI) 
Version 1.0 software option. 

Seven appendixes complete the manual. 

Appendix A, DECnet PARAMETER SUMMARY, summarizes all parameters 
included in the Network Management V4.0 NCP commands. There is a 
separate table for each of the entities: AREA, NODE, CIRCUIT, 
LINE, MODULE, and LOGGING. Event parameters are listed in a 
separate table. Applicability and restrictions are presented 
both as defined by Digital Network Architecture and thus relevant 
to all DIGITAL systems, and as implemented specifically for 
DECnet-10 V4.0. 

Appendix B, DECnet COUNTER SUMMARY, summarizes the entity 
counters that can be displayed and zeroed by appropriate NCP 
commands. 

Appendix C, NETWORK RELATED MESSAGES, describes all messages 
related to the execution of NCP commands and the state of the 
network: output responses, informational messages, and error 
messages. 

Appendix D, X.29 CONFIGURATION FILE, describes the information to 
maintain access to the system through the Public Packet Switching 
Network. This appendix explains X29SRV commands and gives 
examples for configuring X29SRV. 

Appendix E, BIBLIOGRAPHY, is a bibliography of suggested 
network-related readings. 

Appendix F, DECnet LINE DEVICES, is a table of currently 
recognized DECnet line devices. 

Appendix G, GLOSSARY, is a glossary of network terms. 



MANUALS REFERENCED 

Depending on your experience and responsibilities, you may need to 
refer to one or more of the following manuals, which contain more 
detailed information on procedures or programs related to DECnet-10 
Version 4.0 and PSI Version 1.0. 

TOPS-10 DECnet and PSI Installation Guide 

This manual describes the configuration of DECnet-10 nodes 
in a DECnet network and details all generation, 
verification, and installation steps. It describes the 
DECnet-10 configuration tools, the procedures to generate 
the DN20 subsystem, the NETGEN (NETwork GENeration) and 
NIPGEN (Network Installation Procedure GENerator) programs. 
This manual also provides a sample system configuration. 

TOPS-10/TOPS-20 SPEAR Manual 

This manual describes the SPEAR program, a library of 
functions that analyzes and reports on error and significant 
event information recorded by the operating system in the 
ERROR. SYS file. DECnet-10 operating systems record entries 
for loads, dumps, and startups as well as errors. You use 
the SPEAR program's functions RETRIEVE and SUMMARIZE to 
produce reports of errors and events recorded for DECnet-10. 

TOPS-10 PSI User's Guide 

This manual contains information on the following: 

o Writing FORTRAN-10 and MACRO-10 programs that use the 
TOPS-10 X.25 software to access a PPSN. 

o Using the TOPS-10 X.29 software to connect a terminal 
through a PPSN - to a TOPS-10 host. 

The PSI Network-Specific Information cards, which include the 
following : 

PSI NSI PSS Card AV-N804A-TE 

PSI NSI DATANET-1 Card AV-N805B-TK 

PSI NSI TRANSPAC Card AV-N806B-TK 

PSI NSI TELENET Card AV-N807B-TK 

PSI NSI DATEXP Card AV-N808A-TE 

PSI NSI TYMNET Card AV-X57 3A-TK 

You should also refer to the following non-DIGITAL publications for 
the PSI software option: 

CCITT publications that contain complete information on 
recommendation X.3 (PAD) parameters. (See Appendix E for a list 
of CCITT publications.) 

Documentation provided by the user's PPSN (TELENET, for example). 
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EFFECTIVE USE OF THIS MANUAL 

The following suggestions are offered for your effective use of this 
manual : 

o Beginning with Chapter 4, after you have read each chapter, 
take the manual to your terminal and enter the commands given 
in examples, adjusting parameters as needed to conform to 
your site's implementation and conventions. The NCP command 
language has many features that make it easy to use, 
including the "?" feature, command recognition mode, and 
command abbreviation mode (see Chapter 4). 

With the exception of the NCP SHOW commands, any command that 
changes parameter values has the potential for interfering 
with the network activities of another network user. When 
possible, practice under supervision and always work within 
the guidelines set by the system manager. You can avoid 
conflicts by using the OPR command SEND to inform one or all 
network users of your intentions. Such messages as the 
following will be helpful to others on the network: 

15:47:40 From Operator Terminal 23: 
=>Reloading DN20 in 5 minutes 

16:30:25 From Operator Terminal 25: 
=>Restarting Galaxy in 5 minutes 

You can also use the monitor SEND command to produce 
messages in the following format: 

;;TTY51 - Restarting NML. . . 

o System managers and operators using NCP commands to monitor 
and control all nodes should read the entire manual. If your 
network includes DIGITAL operating systems other than 
TOPS-10, you should also read the appropriate manuals for 
those operating systems, if you are a central operator in 
the operations room, you will require a working knowledge of 
all procedures in Chapter 3. Reading the remainder of the 
manual is optional. 
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CONVENTIONS USED IN THIS MANUAL 

The following conventions are used In this manual in command 
descriptions and in examples of dialogue: 



UPPERCASE BOLD PRINT 
lowercase letters 

[ ] 
{ } 

<RET> 
<ESC> 

<CTRL/X> 

numbers 



indicates what you type in a command string. 

indicate an input variable type in a command 
string. For example, if the command 
description specifies "seconds," you might 
type "2" to indicate "2 seconds." 

indicate optional input. (Do not include 
brackets when you type the command.) 

indicate that one of several enclosed 
parameters is applicable. (Do not include 
braces when you type the command.) 

means press the key labelled RETURN or CR. 

means press the key labelled ESC, ALT, or 
SEL. 

means hold the CTRL key and press character 



key 



at the same time. 



All numeric values that appear in this manual 
are decimal numbers, unless otherwise noted. 



The following abbreviations are used in this manual: 

DLL Data Link Layer 

DNA DIGITAL Network Architecture 

IPCF Inter Process Communications Facility 

LAT Local Area Transport 

MCB Multifunction Communication Base 

NCP Network Control Program 

NICE Network Information and Control Exchange protocol 

NML Network Management Layer 

NSP Network Services Protocol 

PSI Packetnet System Interface 

PPSN Public Packet Switching Network 
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REVISION HISTORY 

This revision supercedes the TOPS-10 DECnet-10 System Manager's and 
Operator's Guide, order number AA-L413A-TB, and the TOPS-10 PSI System 
Manager's and Operator's Guide, order number AA-CK83A-TB. 

The TOPS-10 PSI gateway software was released after TOPS-10 Version 
7.02 (DECnet V3.0) , thus the TOPS-10 PSI System Manager's and 
Operator's Guide was created. The TOPS-10 PSI gateway software is 
available for TOPS-10 7.03 (DECnet V4.0) , thus the information in the 
PSI manual was merged into this revision, the TOPS-10 DECnet and PSI 
System Managers' s and Operator's Guide. 

In addition to the PSI information, this revision includes the 
features of DECnet-10 Version 4.0, which include: 

o The Ethernet device NIA20, which provides multi-access 
connections between nodes on the same Ethernet circuit 

o Phase III compatibility 

o The AREA and MODULE entities 

o Phase IV routing nodes and Ethernet non-routing nodes 

o Area routing 

o New upline dump/downline load procedures 

o Multiple FAL streams 
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PARTI 
INTRODUCTION 



CHAPTER 1 
SYSTEM OVERVIEW 

1.1 DIGITAL NETWORK ARCHITECTURE AND DECnet 

DIGITAL Network Architecture (DNA) is a model by which DIGITAL 
computer networks can be built. DNA presents a layered structure, 
each layer corresponding to a major network function. A well-defined 
set of interfaces allows each layer to communicate with its adjacent 
layers; protocols provide rules and conventions for exchange of 
information between corresponding layers in communicating nodes. See 
Figure 1-1. 

DECnet-10 Version 4,0 is the fourth generation (Phase IV) of 
implementations based on the DNA model. The following general 
description of DNA will be helpful to both system managers and 
operators with network management responsibilities. 

NOTE 

TOPS-10 systems can also contain ANF-10 networks. 
ANF-10 and DECnet-10 are totally independent networks 
that can coexist in a TOPS-10 system. 

The DNA model specifies functions to be carried out in software 
modules that implement each layer. How the functions are implemented, 
and which functions are implemented depends on the operating system. 
For example, an operating system with a small amount of memory may 
choose to implement only the minimum subset of Network Management 
functions; an operating system with a communications front end (DN20) 
may choose to implement all Network Management functions. If you know 
the functions that each node in your network implements, you can save 
time and effort. This information is available in the manuals for the 
various DIGITAL operating systems. Personal contact with the system 
managers of all nodes in your network is highly recommended. 
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Figure 1-1: Communication Between Adjacent and Equivalent Layers of 
the Digital Network Architecture 
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The major features of DNA are: 

o Transparency, In the context of the network, the system 
manager or operator is the "user" of a DECnet utility, the 
Network Control Program (NCP) . Once NCP is invoked, the 
"user" is the module or routine that uses the capabilities of 
the layer beneath it in the functional hierarchy. After you 
type a command, all processing and routing of your request 
depends on the system. You receive responses informing you 
of success or failure, 

o Local autonomy. The node that is to execute an NCP command 
retains the right to refuse to do so, A refusal is 
accompanied by a reason in the DECnet-10 V4,0 implementation. 
The nature of the reason determines whether or not you should 
repeat the command at a later time, 

o Flexibility, The modular orientation of the layered 
structure lends itself well to the inclusion of new modules 
and new layers, (See Section 1,2,) 

o Upward compatibility. Each new DECnet phase is compatible 
with the previous phase. For example, a Phase IV node can 
communicate with a Phase III node, but not with a Phase II 
node, 

o Adaptability to the needs of individual operating systems. 
Within the limits set by Phase IV minimum requirements, each 
operating system implements only those functions appropriate 
to that operating system, 

o Distributed or central management capability. The Network 
Management Layer of each DECnet-10 V4,0 node has access to 
all other NMLs through the Network Information and Control 
Exchange (NICE) protocol. Thus, operators at any node can 
control network management functions at any node in the 
network, given the required willingness and capability on the 
part of the remote node. When desired, a single node can 
perform centralized management of the entire network. 



1.2 THE LAYERED STRUCTURE OF DNA 

The layered structure of DNA provides an easily upgraded product. 
Adding new functions, and consequently new layers and modules, is 
easily accomplished during product development. 

The User Layer, Application Layer, and Network Management Layer carry 
out user functions; the Session Control Layer, the End Communication 
Layer, and the Routing Layer carry out network functions; and the Data 
Link Layer and Physical Link Layer carry out the physical aspects of 
communication, 

A brief description of each of the DNA layers, as implemented for 
DECnet-10 V4.0, follows, (See Figures 1-1 and 1-2,) 
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1.2.1 The User Layer 

The User Layer supports user services and programs. NCP, the command 
set of the Network Control Program, is in this layer. User-written 
programs (MACRO programs using DECnet monitor calls) also reside in 
this layer. 
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Figure 1-3: OPR/NCP/NML Logical Processing Flow in DECnet-10 V4.0 
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The Operator Command Language program, OPR, parses all NCP commands. 
Correctly formatted commands that can be processed by OPR (when no 
action by NML is necessary) are processed and executed immediately. 
All other NCP commands, whether to be executed by the local node or by 
a remote node, are passed to the NCP Receiver in NML. Commands that 
already have access to required data are processed and executed 
immediately. All other commands are translated from NCP to NICE 
message format and placed in the Request Queue. 

The Request Queue also receives input from a NICE Receiver. The NICE 
Receiver receives these NICE messages from a remote node for 
processing at the local node. All NICE messages for processing by the 
local node pass from the Request Queue to the local NML processor. 
The local NML Processor directs these messages to appropriate routines 
that process local functions. NICE messages in the Request Queue for 
processing by a remote node pass to the NICE Transmitter, which sends 
them to the remote node. 

All NCP commands that are translated into NICE messages receive a 
response. Commands that are processed before reaching the Request 
Queue do not require a response. There is little delay and the timely 
execution of the command at the local node serves as adequate 
response. Note that there are two paths for responses from the NML 
processor. 

If the local node is both the command node and the EXECUTOR, the 
response is from the local node and to the local node. if you type 
the command at your local node but set the EXECUTOR to a remote node, 
the response is from the remote node to the local node. The response 
to a command typed at a remote node for processing at the local node 
is displayed at the remote node where the command is entered. 

Other processes within the Network Management Layer are: 

The Data Link Watcher monitors the Data Link Layer (DLL) . This 
module detects a service request on a line from an adjacent node. 
The Data Link Watcher reads the request (a MOP protocol message) 
and either services the request itself or passes an appropriate 
request to the Upline Dumper or Downline Loader process. This 
service request is generated by the monitor in response to a 
protocol crash. In DECnet-10 the Data Link Watcher is in the 
KL10 processor only (not in DN20 processor) . In the TOPS-10 KL10 
node, the Data Link Watcher services load and dump requests from 
both MCB and Ethernet nodes. 

The Event Receiver receives remotely-generated event messages and 
checks these messages for proper syntax. Syntactically correct 
messages are sent to the Event Recorder. 

The Event Recorder determines which sink to send messages to and 
distributes the messages to the indicated event sinks. 
(DECnet-10 only supports the FILE sink and CONSOLE sink to OPR 
jobs, and messages are logged in the SYS: ERROR. SYS file.) 

The Event Processor processes event messages, and sends the 
processed event messages, along with 9 date and time stamp, to 
either the local Event Recorder or to an Event Transmitter for 
transmission to a remote Event Receiver, 

The Event Transmitter uses a logical link to transmit event 
messages to the Event Receiver of the remote node (the sink 
node) , 
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The Loop Message Generator is responsible for all loop functions 
(used for testing and maintenance) , both those associated with a 
CIRCUIT or LINE and those associated with a NODE. Node loopback 
data is dispatched to the Loopback Mirror, The primary function 
of the Loopback Mirror is to reflect back to the Loopback Message 
Generator either the test message or an appropriate error 
message. CIRCUIT or LINE loopback is accomplished with or 
without hardware assistance. In a DECsystem-1090/1091/1095 , 
there is a Loopback Mirror in both the KL10 and the DN20 
processors. 

The Downline Loader, using the MOP protocol, loads an adjacent 
DN20 or Ethernet node from the KL10 host. 

The Upline Dumper acts as a receiver of a dump from an adjacent 
DN20 or Ethernet node. The dump is stored in a file in the host 
node. 



1,2.3 The Network Application Layer 

This layer supports I/O devices and file access. Modules within this 
layer include the Loopback Mirror, Network File Access, and the File 
Access Listener. 



1.2.4 The Session Control Layer 

This layer defines a mechanism that allows a program in one node to 
communicate with a program in another node, regardless of either 
program's location in the network. This mechanism is called a logical 
link, and modules in the User Layer, the Network Management Layer, and 
the Network Application Layer can use it. 



1.2.5 The End Communication Layer 

The End Communication Layer was referred to as the Network Services 
Layer in previous DECnet-10 versions. Modules in this layer, using 
the Network Services Protocol (NSP) , control the system- independent 
aspects of communications that use the logical link. These include 
connection management, data flow control, end-to-end error control, 
and segmentation/reassembly of user messages. Logical links provide 
the network's primary user-to-user communication. It is the End 
Communication Layer that guarantees delivery of all transmitted data 
in proper sequence. 



1,2.6 The Routing Layer 

The Routing Layer was referred to as the Transport Layer in previous 
DECnet-10 versions. This layer provides routing-related processing. 
The Routing module first determines if the target node is "reachable," 
that is, whether there is a path from the sending node to the 
specified receiving node. If there is not, you receive an appropriate 
message. if there is, a table lookup is performed. The message is 
directed to the first node along the least-cost path, (Routing 
concepts are explained in more detail in Section 2,4.) 
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1,2.7 The Data Link Layer 

This layer controls message sequencing and data integrity for 
communications between adjacent nodes, whether they are connected by 
an X.25 link, an Ethernet link, or a DDCMP link. It does not 
guarantee delivery, but it does ensure error-free communication 
between adjacent nodes once communication is established. 

NOTE 

In all nodes in your network, the Data Link Block Size 

must be the same. If you do not follow this rule when 

a node is added to the network, the new node may lose 

data when communicating with the other nodes in your 
network. 



1.2.8 The Physical Link Layer 

This layer defines the way that device drivers and communications 
hardware (such as modems and lines) are used to move data over a 
transmission line. 



1.3 THE DECnet-10 VERSION 4.0 IMPLEMENTATION 

DECnet~10 Phase IV runs on a KL10-based or KS10-based system. Both 
the KL10 and KS10 support a subset of Network Management V4.0. 

On KL10 systems, the DN20 communications front end with 128K words of 
memory is a DECnet Phase III node. Although the KL10 and the DN20 are 
two separate nodes, they work together as a system. The KL10 can 
utilize the DN20 capabilities to communicate with Phase III nodes, but 
not with Phase IV nodes. To communicate with Phase IV nodes, the KL10 
requires an Ethernet port. 

KS10 systems support Phase IV directly over KDP lines. 

DECnet-10 does not have a modifiable permanent data base and therefore 
does not support the NCP commands DEFINE, PURGE, and LIST. Data base 
values established during network generation are read from command 
files at system startup and become the initial parameter values in the 
volatile data base. 

Appendix A summarizes all possible parameters and describes both DNA 
and DECnet-10 applicability ("applies to EXECUTOR only", for example) 
and restrictions ("display only", for example). 
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1.4 DECnet-10 V4.0 HARDWARE 

The KS10 (2020) processor running TOPS-10 allows direct Phase IV 
connection by means of KDP (KMC/DUP-11) lines. The system can have 
one or two DECnet lines. 

On KL10 (DECsystem-1090/1091/1095) systems, the basic hardware 
configuration contains: 

o The KL10 Central Processing Unit running TOPS-10 software. 
The KL10 is a full DECnet~10 Phase IV node. 

o The console front end running RSX-20F. This front end 
assists the CPU by handling the operator's console, terminal 
communications, unit record peripherals, and diagnostics. 

o The communication front end (DN20) running the Multifunction 
Communication Base (MCB) software. MCE software includes the 
V3.0 DECnet-10 functions. The DN20 is a full DECnet-10 Phase 
III node. 

o The DTE hardware interfaces between the main processor and 
the two front ends. 

o The NIA20 provides multi-access connections between nodes on 
the same Ethernet circuit. Ethernet messages are sent over 
the Ethernet as datagrams, which means messages can be lost 
because of errors. DECnet-10 provides for automatic 
retransmission of lost messages; therefore data integrity is 
guaranteed. The Ethernet device allows multiple users of the 
device at the same time. Up to one NIA20 per CPU is 
supported, but only one Ethernet. 

o Communication devices as required. 

A single KL10 can support up to three DN20 communications front ends 
for DECnet-10. Multi-CPU systems can support up to three on each CPU. 

The PSI Version 1.0 software option restricts the basic hardware 
configuration. See the Software Product Description (SPD) for more 
information. 

NOTE 

Although a KL10 processor can support three DN20s, 
only one PSI Gateway is supported per system. 



1-9 



SYSTEM OVERVIEW 

1.5 DECnet IMPLEMENTATIONS 

A DECnet network can consist of nodes running various DIGITAL 
operating systems, each with its own implementation of DECnet, The 
concepts underlying the implementation are the same, but the functions 
implemented may differ. 

DECnet-10 V4 . implements a subset of the NCP commands in the Phase IV 
DNA Network Management V4.0 Specification. Not all the parameters 
that can be formatted and interpreted are supported. You receive no 
"action response" if you use a command not implemented at the 
receiving end. The response you receive is usually: 

Unsupported Function or Option 

DECnet implementations provide the ability to send commands to a 
remote node for execution at the remote node. Because it is a Central 
Management node, the DECnet-10 host node can format and send commands 
supported by other DIGITAL hosts, even though the commands are not 
supported locally. 



1.6 DECnet-10 CAPABILITIES 

DECnet-10 capabilities are available to the nonpr ivileged terminal 
user, the programmer, and the system manager or operator. The TOPS-10 
Operating System Co mmand s Manual describes the DECnet functions 
available to nonpr ivileged terminal users and programmers. The 
TOPS-10 DECnet and PSI System Manager' s and Operator' s Guide is 
specific to the operational , control, and monitoring functions that 
are normally the responsibility of the system manager or operator. 

The system manager and operator use the NCP commands to control and 
monitor the network. It is the system manager's responsibility to 
inform the staff of critical commands that should be used by only 
designated operators, or used during off-hours only. Chapters 4 
through 7 describe the NCP command set in detail. Chapter 4 
summarizes the general functions and features of NCP. Chapters 5, 6 
and 7 describe the specific function of each command and the meaning 
of allowed arguments. 

DECnet-10 capabilities include: 

o Adaptive path routing. Permits messages to be routed through 
the network over the most cost-effective path; messages are 
re-routed automatically if the circuit is disabled. Routing 
nodes can send and receive messages by routing through 
intermediate nodes. When a line or system failure occurs, 
and an alternate path exists, the alternate path is chosen. 
Adaptive path routing is transparent to the user. The system 
manager or delegated operator can change a routing path 
indirectly with an NCP command. 

o Heterogeneous network command terminals. A user at one node 
can log into the system at another node in the network if 
both systems are running DECnet Phase IV and the CTERM 
protocol . 

o Support of nodes of varying capabilities and configurations. 

DECnet-10 allows end nodes (nodes that can send and receive 

but not forward) to coexist on the network within the 
restrictions described in Section 2.5.1. 
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Because DECnet-10 Version 4.0 nodes are Central Management 
Nodes, the Network Management modules understand the complete 
command set for DECnet Phase III and DECnet Phase IV. Thus, 
using the TELL command prefix, you can direct NCP commands 
not supported locally to other Phase III or Phase IV nodes on 
your network. A DECnet-10 V4.0 node can format any command 
that a remote DECnet Phase III or DECnet Phase IV node can 
execute. This includes multipoint commands. 

Extensive network management capability. Using NCP, the 
system manager and operator can control and monitor network 
activity from one or multiple nodes in the network. You can 
change entity states and characteristics in the volatile data 
base (also in the permanent or temporary data base using the 
TELL command prefix to nodes that support it) . You can also 
display both current and recent network activity. Loopback 
tests, downline loading and upline dumping are available 
through NCP commands. 

Logging of significant events. You can reset and display 
activity counters (see Appendix B for details). Certain 
events and errors (start-ups, dumps, hardware detected 
errors, for example) are also entered in the file ERROR. SYS. 
You can use the SPEAR program to create reports according to 
the specifications you select. You can also log events to 
the CONSOLE sink. 

File transfer operation. You can copy, delete, or display a 
file from and to a remote node; you can obtain a directory 
from a remote node; you can submit a batch control file to a 
remote node. 



1.7 OVERVIEW OF NCP COMMAND KEYWORDS 

The command keyword specifies the action you request. The command 
keyword is always the first part of the command that you type. 
Command keywords may or may not be followed by an entity (a 
controllable network element such as a node or circuit) and one or 
more parameters (values indicating characteristics or status of an 
entity) . Most commands to remote nodes include both entity and 
parameter (s) . Commands addressed to the local node can have entity or 
parameter or both implied. Thus, a complete command can consist of 
the command keyword, the entity, and the parameter. 

Each of the commands illustrated below is complete. 

Command keyword only: 

NCP>EXIT 
NCP>HELP 

Command keyword and entity: 

NCP>SHOW EXECUTOR 

Command keyword, entity, and parameter: 

NCP>SET EXECUTOR NODE node id 
NCP>ZERO CIRCUIT cktid COUNTERS 

A complete list of NCP command keywords follows. The order is 
alphabetic for ease of reference. Refer to the section indicated for 
a more specific description of function, 
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Table 1-1: NCP Command Keywords 



Command 


Function 


Complete 
Description 


CANCEL 


Removes a command from the 
Request Queue before 
processing begins. 


Section 6.6 


CLEAR 


Removes a value previously 
entered in the volatile data 
base. 


Section 6.3 
(EXECUTOR) 
Section 7.6 
(All entities) 


DEFINE 


Enters a value in the 
permanent data base. 


Section 6.2 
(EXECUTOR) 
Section 7.5 
(All entities) 


DUMP 


Stores a copy of a target 
node' s memory image in a dump 
file at the host node. 


Section 7.8.1 


ENTER 


Accesses a subset of OPR 
commands when typed to the 
OPR prompt . 


Section 5.1 


EXIT 


Terminates an NCP session and 
returns control to TOPS-10 
monitor level. 


Section 5.1 


HELP 


Returns the function and 
major keywords for all NCP 
commands. 


Section 6.8 


LIST 


Displays on the user's 
terminal information from the 
permanent data base. 


Section 7.7 


LOAD 


Allows the executor node to 
load the system image file to 
a remote node adjacent to the 
executor. 


Section 7.8.2 


LOOP 


Requests a node-level 
loopback test. 


Section 7.8.3 


PURGE 


Removes a value or values 
from the permanent data base. 


Section 6.4 
(EXECUTOR) 


PUSH 


Changes control from NCP to 
TOPS-10 command level. 


Section 5.1 
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Table 1-1: NCP Command Keywords (Cent.) 



Command 


Function 


Complete 
Description 


RETURN 


Switches OPR from the NCP 
command set to the standard 
OPR command set. 


Section 5.1 


SET 


Enters a value or values in 
the volatile data base. 


Section 6.1 
(EXECUTOR) 
Section 7.5 
(All entities) 


SHOW 


Displays on the user's 
terminal information from the 
volatile data base. 


Section 6.5 
(SHOW QUEUE) 
Section 7,7 
(SHOW entity) 


TAKE 


Retrieves and executes a file 
of NCP commands. 


Section 5.1 


TELL 
(prefix) 


Directs the command that 
follows to a remote node for 
execution. 


Section 6.7 


TRIGGER 


Requests the target node to 
send a load request. 


Section 7.8,4 


WAIT 


Used in batch programs, 
delays processing the next 
command for the specified 
number of seconds. 


Section 5.1 


ZERO 


Logs counters and then zeroes 
them. 


Section 7.9 
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CHAPTER 2 
NETWORK CONCEPTS 



2.1 NODES AND DATA LINKS 

Nodes and data links are the two fundamental elements in the network. 
As used in this document, a network node is a computer processor that 
can pass data, using DECnet, to one or more remote nodes. Network 
nodes are classified in several ways. One basic classification 
divides nodes into local and remote. For typing NCP commands, the 
local node is usually (could be SET HOSTed) the node where your 
terminal is located (the TOPS-10 node in DECnet-10) . All other nodes, 
including the MCB front end, if any, are remote. 

In the DECnet software, the local node is the node acting as EXECUTOR; 
this is usually, but not always, the node at which you type the 
command. Any active node in the network is remote to any other active 
node in the network. Thus, by definition, the central processor is 
remote to its connected MCB front end. An adjacent node is one that 
is physically connected to the node that it is termed "adjacent to." 
For example, on KL10 based systems, the MCB front end is adjacent to 
the KL10 central processor. 

Nodes are also classified according to their network function. In 
descriptions of network functions, you will frequently see the terms 
command (or control) node, executor node (or EXECUTOR), target node, 
and host node. The command node is the node where you type a command. 
The executor is the node where the command is executed. The target 
node is the node where the action requested by the command takes 
place. The host node is the node where resources for processing the 
command exist (storage space for files, for example). These 
functional classifications are not mutually exclusive. For example, a 
node can serve as executor, command, host node, and target node. See 
Figure 3-2. 

Data links are actual physical connections between nodes; Logical 
links are logical connections. A physical link connects node A to 
node B, for example; a logical link connects Marcia at one terminal to 
George at a remote terminal, or connects a user process at one node to 
a utility process at another node. The logical link encompasses the 
end-to-end transmission of data. Lines are the physical media for 
logical links. In a logical link from node A to node C by way of node 
B, there is one logical link but there are two physical links. The 
term "circuit" is synonymous with a logical point-to-point connection. 
Section 7.3.4 describes circuits in more detail. 
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2.2 THE PS I GATEWAY 

The PSI Gateway interfaces a DECnet network to an X.25 Public Packet 
Switching Network (PPSN) over a leased data communications line. The 
internationally recommended protocol for such an interface has been 
defined by CCITT Recommendation X.25. The Gateway's main 
responsibility is to generate and interpret the protocol messages 
necessary to communicate with the X.25 node at the opposite end of the 
data link which connects the DN20 to the PPSN. 

The PSI option also includes software to permit access to the Gateway, 
and thus the X.25 network, from a TOPS-10 DECnet Version 4.0 node. 
These software units include the Gateway Access Library and the X.29 
Server. Figure 2-1 illustrates the placement of the TOPS-10 PSI 
Gateway Access Library Routines and the TOPS-10 Gateway Software in 
the central (TOPS-10) processor and the communications processor 
(DN20) . 
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Figure 2-1: TOPS-10 PSI Gateway Software Components 
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The Gateway Access Library is a collection of subroutines that the 
user can use to write programs and applications that perform X.25 
functions (see the TOPS-10 PS I User' s Guide ) . These routines are 
linked with the user' s software to form a single-job image. The 
routines allow communication with the Gateway by using the Gateway 
Access Protocol over a DECnet logical link. This permits user 
programs to directly manipulate the X.25 protocol at the Gateway's 
interface to the X.25 network, even though the user may be on a DECnet 
node that is geographically distant from that interface. 

The X.29 feature permits a user at an asynchronous terminal to log in 
to a TOPS-10 system that has access to an X.25 network. The terminal 
is connected to a Packet Assembly/Dissembly (PAD) , either through a 
direct asynchronous connection or a modem. The X.29 Server uses the 
X.29 protocol to control the terminal session through communication 
with the PAD. The X.29 Server uses the Gateway Access Protocol to 
communicate with the Gateway. It communicates with the NRT Server in 
the TOPS-10 host using the Network Remote Terminal Protocol (NRTP) . 
Figure 2-2 illustrates the components needed for such a connection. 
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Figure 2-2: X.29 Terminal Access to a TOPS-10 Host 
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2.3 ENTITIES 

The term "entity" is used in reference to NCP commands. An entity is 
the element on which the command is to act: for example, in the 
command SET NODE nodeid HOST hostname, NODE nodeid is the entity; or 
in the command SHOW ACTIVE LINES COUNTERS, ACTIVE LINES is the entity. 
An entity in the singular form is one of: AREA, CIRCUIT, LINE, 
LOGGING, MODULE and NODE. ACTIVE and KNOWN preceding AREAS, CIRCUITS, 
LINES, LOGGING, MODULES and NODES permit plural forms. NODE has two 
other forms, LOOP NODES and ADJACENT NODES. Chapter 7 describes 
entities in detail. 

The MODULE entity is provided for users of the TOPS-10 X.25 software 
(discussed in Chapter 8) and for maintenance of the Ethernet, The 
MODULE entity for X.25 takes one of three forms: MODULE X25-ACCESS, 
MODULE X25-PROTOCOL, and MODULE X25-SERVER. 



2.4 ROUTING CONCEPTS 

Routing, the primary function of the Routing Layer, is the 
determination of the physical path that packets follow between nodes. 
This path is determined at each node. At each intermediate node, the 
Routing module reads the header of an incoming packet to determine its 
destination, then reads the routing table to determine the least-cost 
path. Within the limits set by the configuration, the routing table 
is automatically updated when a path is no longer an acceptable 
choice. The system manager or operator can also change the path using 
the appropriate NCP command (SET CIRCUIT cktid COST cost) , See Figure 
2-3, 
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Legend: 



r^ = node 



arrow ~ direction associated with n 
" n = cost of circuit 



Node E Is a non routing node; nodes A, B, C, and D are routing nodes; 
ail nodes are Phase III nodes. 
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NCP Commands for Control: 



FOR EXECUTOR 



FOR CIRCUIT 

SET CIRCUIT DMR-0 COST 3 SET EXECUTOR MAXIMUM COST 30 

SET CIRCUIT KDP-0-2 COST 4 SET EXECUTOR MAXIMUM HOPS 4 

SET CIRCUIT DTE -1-3 SET EXECUTOR MAXIMUM VISITS 8 



Figure 2-3: Routing for DECnet-10 V4,0 
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2.4.1 Node Routing Types 

DECnet-10 Version 4.0 routing supports two major types of nodes: 
routing nodes and Ethernet nonrouting nodes (end nodes). The 
characteristics and capabilities of the two major types of nodes 
follow. 

o Routing Nodes 

Routing nodes (routers) allow communication between nodes 
that are not adjacent. 




Figure 2-4: Routing Node 



Routers can have one or more circuits. Routers regularly 
receive and maintain information about other nodes. They 
perform the routing operation by associating a circuit with 
the destination node for the packet and transmitting that 
packet over that circuit. Routers can use DDCMP, Ethernet, 
or X.25 circuits as their data links. 

In Figure 2-4, neither A nor C is aware of B's participation 
in the routing above the DNA Routing level. Thus, the 
operator perceives the connection as a direct A to C 
connection. If all nodes in the network are routing nodes, 
then each node can communicate with every other node in the 
network. 

o Nonrouting Nodes 

Nonrouting nodes (end nodes) contain a subset of network 
software that permits them to send packets or receive packets 
addressed to them, but not to route packets to other nodes. 
In DECnet-10, only Ethernet nodes can be end nodes. End 
nodes have a single circuit, ETH-0 , connecting them to the 
rest of the network. They do not send or receive information 
about network configurations. If two end nodes are connected 
by a nonbroadcast circuit, these nodes constitute the entire 
network. 

On an Ethernet, if there are two or more routers, one router 
is designated the router to provide message routing services 
for end nodes on the Ethernet, If no routers are available, 
Ethernet end nodes can communicate with each other directly, 
by sending a packet out over the Ethernet and then waiting 
until the timeout for a reply. However, routers are the only 
Ethernet nodes that can route messages to nodes not on the 
Ethernet, 
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MR-S-2041-e2 



Figure 2-5: Nonrouting Nodes 



In Figure 2-5, nodes A, B, C, and D are routing nodes; nodes 
E and F are nonrouting nodes. E can send messages to A, B, 
C, D, F, and itself, and can receive messages from each of 
them. Similarly, F can communicate with A, B, C, D, E, and 
itself. As long as each node in the path from E or F to the 
destination node is a routing node, messages can continue 
through the network for a maximum of six hops. Messages from 
any node to E or F can also continue in this manner. 

The placement of the nodes diagrammed suggests that D does 
more communicating with E and F than with A, B, and C. Note 
that if B goes off line, D (and E and F) cannot send to or 
receive from A, B, or C, The network shown also suggests 
that A, B, and C expect to communicate with each other more 
than with D. Note that each of these nodes has a direct path 
to each of the others: one direct one-line or "hop" path; 
and one two-hop path: for example, A to B and A to B through 
C. 

In planning your network, the number of routing nodes should be kept 
down because of the overhead associated with routing. You should try 
to minimize the use of routers and maximize the use of end nodes. 
Although end nodes are less flexible than routers, they require less 
memory and have less system overhead. Often, by using fewer routing 
nodes, you can get better system performance. 



2.4.2 Area Routing 

Phase IV DECnet supports the configuration of very large, as well as 
small, networks by dividing the network into areas. In a single-area 
network, a maximum of 1023 nodes is possible, but the optimum number 
of nodes is much less (approximately 200 to 300 nodes, depending on 
the topology) . Area routing techniques permit configuration of very 
large networks, of up to 63 areas, each containing a maximum of 1023 
nodes. In a multiple-area network, nodes are grouped into separate 
areas, each functioning as a sub-network. DECnet supports routing 
within each area and a second, higher level of routing that links the 
areas. Nodes that perform routing within a single area are called 
level 1 routers; those that perform routing between areas as well as 
within areas are called level 2 routers (or area routers) . 
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DECnet-10 does not perform level 2 routing. However, a DECnet-10 
system can use the services of systems that support level 2 routing to 
participate in area-organized networks. For more information on 
configuring area networks, refer to the DECnet manuals for operating 
systems that support this function. 

Area routing offers the following advantages: 

o Permits configuration of very large networks of more than 
1023 nodes. 

o Requires less routing traffic, restricting routing overhead 

between areas to the level 2 routers. Level 1 routers 

exchange routing information about nodes in their own area 
only. 

o Allows different organizations to manage their nodes 
separately within a large network. 

o Makes the merging of existing networks easier. 

A DECnet-10 system connected to the network by the Ethernet can 
communicate with all nodes in an area network (with a level 2 router) , 
whereas a system connected by a DN20 can only communicate with at most 
255 nodes in that system's area. In particular, the DN20 can only 
communicate with nodes whose node address is less than 256 (such as, 
nodes 1-255) in the same area as the DN20. 



2.4.3 Level 1 and Level 2 Routers 

DECnet-10 nodes cannot perform area routing, however they can 
participate in area configurations that use non-DECnet-10 nodes as 
area routers. 

An area can contain many level 1 routers and end nodes, and must 
contain at least one level 2 router to provide the connection to other 
areas. A level 1 router acts as a standard routing node. It keeps 
information on the state of nodes within its own area. Level 1 
routing nodes and end nodes obtain access to nodes in other areas 
through a level 2 router residing in their own area. 

A level 2 router keeps information on the state of nodes in its own 
area and also information on the cost and hops involved in reaching 
other areas. (The logical distance between adjacent level 2 nodes is 
one hop.) The level 2 router always routes packets over the least cost 
path to a destination area. Level 2 routers have the following 
characteristics: 

o Level 2 routers connect areas together. 

o Level 2 routers also act as level 1 routers within their own 
area. 

o Each level 2 router in a network must be physically connected 
to at least one other level 2 router. 

o A level 2 router serves as a level 1 router when it is not 
physically connected to another level 2 router. 

o All level 2 routers must be connected in such a way that they 
create a network of their own. 
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o Level 2 routers exchange level 2 routing messages among 
themselves . 

o In any given area, there can be more than one level 2 router. 



2.4.4 Ethernet Routers and End Nodes 

Two special concepts are involved in routing over an Ethernet circuit: 
the designated router and end node caching. 



2.4.4.1 Ethernet Designated Routers - The function of the designated 

router is to route messages over the Ethernet on behalf of end nodes. 

A designated router is elected even if there are no end nodes 
currently on the Ethernet. 

If there are two or more routers on the same Ethernet, one of them is 
elected as the designated router. By convention the router with the 
highest numerical priority (set with the command SET CIRCUIT ROUTER 
PRIORITY) is elected router for the circuit. In case of a tie, the 
node with the highest address is elected as the designated router. 

The designated router broadcasts messages telling end nodes that it is 
available for routing. End nodes transmit multicast hello messages, 
so that routers know of their presence on the Ethernet. 

End nodes keep no information about the network configuration, except 
that they are permitted to keep a cache of nodes within their area 
that they may address directly on the Ethernet, rather than going 
through a router (see the description of Ethernet end node caching 
below) . Thus an end node may send a packet directly to another 
Ethernet end node, if the address has been cached, or it may send a 
packet to the designated router for forwarding. 

Note that end nodes can exist on an Ethernet without a router. When 
an end node on the Ethernet wishes to communicate with another end 
node, and notes that no designated router exists, it will always send 
the packet directly to the addressed node. If the addressed node is 
active, the sender will receive a reply; if the addressed node is not 
available, a timeout will occur. 



2.4.4.2 Ethernet End Node Caching - End nodes normally send packets 
by means of a router. To minimize the space and time overhead 
involved in the routing function on Ethernet circuits, a caching 
mechanism is available that takes advantage of the fact that nodes on 
an Ethernet are logically one hop away from each other (one hop is the 
distance between two adjacent nodes) . 

When a designated router is present and an end node is ready to send a 
packet to a node for the first time, the end node sends the packet to 
the designated router. When there is no designated router on the 
circuit, the end node sends the packet directly, in expectation that 
the other node is there. If a response is received, the end node 
examines the received packet to see if the "on-Ethernet" bit is set 
(the bit is checked even if the first packet went to the designated 
router). If the bit is not set, no action is taken; if the bit is 
set, the next packet can be sent directly, rather than by means of the 
designated router. 
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An end node's cache contains the addresses of end nodes that the node 
has communicated with within the last minute. When a minute has 
passed without receiving a message from the node, the node's address 
is removed from cache. 

The buffer size to be used in a connection is negotiated during the 
connect process. This process can occur directly between two end 
nodes or with the assistance of a designated router. Once the buffer 
size is negotiated, it cannot be changed. 

The cache time limit can cause links to be aborted when different 
buffer sizes are assigned to end nodes and routers. For example, a 
designated router with a buffer size of 576 bytes initiates a direct 
connection between two end nodes using a buffer size of 1467 bytes. 
(This succeeds because the first packet sent to the router is small, 
always under 576 bytes.) A pause in communications between the two end 
nodes occurs that causes the destination node's address to be removed 
from the sender's cache. The sender attempts to resume communications 
by sending a 1467 byte packet through the designated router's 576 byte 
buffer, forcing the link to be aborted. Therefore, the designated 
router should have the largest buffer size used in the network. 



2.4,5 The Adaptive Least-Cost Routing Algorithm 

Routing and related functions are accomplished in the Routing Layer of 
the KL10 or KS10 node and of the DN20 communications front end. 
Although routing is transparent, you, as the system manager or 
operator can, through the NML interface to Routing, obtain information 
about and control the routing operation. Therefore, you need to 
understand how routing is determined. More specifically, you need to 
understand the significance of parameter changes in the NCP commands 
that you use. The "Routing language" includes a few common terms with 
routing-specific meanings. Figure 2-3 is designed to define these 
terms and, at the same time, provide you with a basic understanding of 
the DECnet-10 routing algorithm. 



2,4.6 Congestion and Packet Delivery 

The Routing Layer attempts to keep network traffic through its node at 
a manageable level. It accomplishes this through stringent assignment 
of buffers. When buffer resources are exhausted, the Routing Layer 
refuses packets from NSP and discards packets from other nodes. 

If the data link remains open, NSP guarantees eventual delivery (once 
it accepts the message from the user) between nodes in a network. 
Timely delivery occurs under normal traffic loads. 
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2.5 SUMMARY OF PHASE III/PHASE IV COMPATIBILITY 

The following types of nodes can exist in a Phase IV network: 

Phase IV Router - This node sends messages to and receives messages 
from other nodes, and routes messages from other source nodes to other 
destination nodes. A Phase iv Router can use one of the following 
circuits: Ethernet, DDCMP, or X.25. In an area network 
configuration. Phase IV routers exist at two routing levels: 

o The level 1 router, which performs routing within a single 
area. The node type is ROUTING-IV. 

o The level 2 router, which performs routing within its own 
area and to and from other areas. The node type is 
AREA-ROUTER. DECnet-10 does not perform level 2 routing. 
However, a DECnet-10 system can use the services of systems 
that support level 2 routing. 

Phase IV Nonrouting Node (end node) 

This node sends messages to, and receives messages from, other 
nodes, but does not route messages, A Phase IV nonrouting node 
can be connected through Ethernet or through DDCMP circuits. For 
DECnet-10, it can be connected only through Ethernet. The node 
type is NONROUTING-IV. 

Phase III Router 

This node sends messages to and receives messages from other 
nodes, and routes messages from other source nodes to other 
destination nodes. It uses DDCMP, and X.25 circuits, but does 
not support Ethernet circuits. The node type is ROUTING-III. 

Phase III Nonrouting Node (end node) 

This node sends messages to and receives messages from other 
nodes, but does not route messages. This node cannot support the 
Ethernet. The node type is NONROUTING-III . 

Phase II Node 

This node can send messages to an adjacent Phase III router or to 
an adjacent Phase II node. However, a Phase II node can send 
messages only in point-to-point configurations. In addition, a 
Phase III node cannot communicate with a Phase II node through 
another Phase III node. A Phase II node cannot communicate with 
a Phase IV node. This node can never be on the Ethernet. 



2.5.1 Topological Restrictions 

The following types of nodes can be configured adjacent to each other 

o Phase Il/Phase II 

o Phase Il/Phase III 

o Phase Ill/Phase III 

o Phase Ill/Phase IV 

o Phase IV/Phase IV 
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Phase IV nodes can communicate with Phase III nodes. Certain 
restrictions apply, however, in a mixed Phase Ill/Phase IV network: 

o A Phase III node should not be included in a path between 
Phase IV nodes. 

o A Phase III node in a Phase IV multiple-area network should 
not be linked with nodes outside its own area. 

o Routing initialization passwords are required when a Phase 
III node is initialized in a phase IV network. 

The following restriction applies to the placement of end nodes: 

o An end node must be adjacent to a routing node. 



2.6 OPERATOR FUNCTIONS AND RESPONSIBILITIES 

An "operator," in the context of this manual, is any terminal user 
with the privileges to run the OPR program, and who is responsible for 
entering NCP commands or running system or network-related programs 
(requiring these privileges) for monitoring or controlling the 
network. 

An operator's duties can consist of well-defined, simple, and 
repetitive tasks, or can consist of complex tasks that cannot be 
predefined. Some operators have responsibilities that combine both 
types of duties. Because of the many variations in personnel and site 
management, your responsibilities as an operator may be quite 
different from those of another operator. However, whatever these 
responsibilities are, it is important that you: 

o Have a clear idea of what your responsibilities are, 

o Have (or gain) both the software and hardware knowledge 
needed to perform your assigned tasks, 

o Consult with the system manager, or someone designated by the 
system manager, whenever you are in doubt about a procedure, 

A few NCP commands have the potential for disrupting the entire 
network. Several commands will, if formatted with valid but 
ill-chosen parameters, at least disrupt your own node's performance. 
Never enter an NCP command without a complete understanding of the 
probable effect of the command. Do not make changes in the permanent 
data base of a remote node without consulting the system manager at 
the remote node. All commands to change either the volatile or 
permanent data base of a remote node must include the required USER 
and PASSWORD parameters. 

A list of functions commonly performed by operators follows. As an 
operator, you may be responsible for any of the following functions: 

o Starting the network automatically 

o Starting the network manually 

o Loading the DN20 manually (the DECnet-10 communication front 
end on KL10-based systems) if required 

o Starting up software or devices needed by the network 
(GALAXY, printer, for example) 
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o Loading and starting adjacent nodes 

o Monitoring local and remote nodes 

o Securing a dump after a crash 

o Changing parameters in the volatile data base 

o Shutting down a node or all network operation 

o Changing the state of network entities 

o Changing the routing path indirectly by changing the circuit 
cost 

o Gathering (and possibly analyzing) statistics (events, 
errors, performance) 

o Running SPEAR for reports on network events and errors 

o Using network command files and possibly creating command 
files to be executed at scheduled intervals 

o Testing network application programs 

o Recognizing potential problems (long response time, high 
error rate, for example) 

o Using diagnostic tools 

o Keeping all network-related logs and forms up-to-date 

Once you have a clear idea of your responsibilities, concentrate first 
on the sections of this manual that describe the functions you need. 



2.7 SYSTEM MANAGER FUNCTIONS AND RESPONSIBILITIES 

The DECnet-10 System Manager has final responsibility for the total 
functioning of the DECnet-10 node in the network. The tasks that the 
manager performs depend on several factors. The principal factors 
are: 

o The degree to which the management of the network is 
distributed. (Will there be standards and procedures from a 
central management node? Is the local node responsible for 
some or all of the control of other nodes in the network?) 

o The complexity of the network of which the local node is a 
member. (Are there non-DECnet-10 nodes in the network? What 
and where are available resources?) 

o The knowledge and experience of the Manager's staff. (How 
can responsibilities best be allocated? What training is 
needed and how can it best be achieved?) 
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Ideally, a system manager concentrates on activities that call for 
planning and require a high degree of knowledge and expertise. 
Actually, however, you may frequently have to perform some of the 
operator duties described in the previous section. Listed below are 
the functions that are the peculiar responsibility of a system manager 
in a "typical" DECnet-10 environment. 

o Generating and installing the DECnet-10 software. A DIGITAL 
Software Specialist performs the original generation and 
installation of the DECnet software. You should, however, 
follow the procedure and read the appropriate manual (see the 
TOPS-10 DECnet and PSI Installation Guide ) . The network may 
grow in number of nodes and other physical resources. As the 
system manager, you may need to repeat some of the steps 
followed in the original generation and installation in the 
future. Some of the parameters established during system 
generation may require change due to changes in resources, 

o Assigning personnel to specific duties. For reasons of 
security, as well as efficiency, operators should be aware of 
those functions they must not perform, as well as those for 
which they have responsibility. For example, certain NCP 
commands have the potential for disrupting services, and 
should be restricted in use. 

o Providing appropriate documentation to all operators who will 
use Network Management functions. 

o Scheduling network services. To the extent possible, network 
startup and shutdown should be set up automatically at the 
times dictated by the nature of the node's needs. At least 
until operators become proficient in their use of the 
network, the manager should consider a schedule of 
stand-alone time for demonstrations and practice. Initial 
schedules should attempt to avoid extremes of traffic, but 
the ideal schedule cannot be built until you have analyzed 
traffic patterns. 

o Handling of physical resources. The manager should provide 
both hard copy and on-line sources of information on the node 
locations of processors, terminals, peripherals, network 
application programs, remote stations, and any other 
facilities used in the network. The manager should provide 
information to all operators on the use of all facilities. 
All resources should be analyzed for performance. Error and 
performance data should be kept for maintenance engineers and 
specialists, as well as for site planning and scheduling, 

o Checking the surveillance log periodically. Whenever OPR is 
running and you have typed "ENTER NCP," the system 
automatically records all network activity. This log 
includes the terminal number where the NCP command was 
entered and contains the command itself. The current log has 
the file name SSL:0PERAT.L0G[3 , 3] . When ORION is started or 
restarted, this file is copied to SSL:OPERAT.nnn[3,3] (for 
example, OPERAT.001 [3, 3] , OPERAT.002 [3, 3] ) , where nnn is the 
next highest generation number. This is the file you can 
examine to observe all NCP activity by date and time. (Use 
the DIRECT monitor command to find the date and time you wish 
to observe because frequently there are multiple files.) 
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o As the system manager, you should at all times be aware of 
the operational status of the network - both nodes and 
devices used in your network activities. Functions you may 
have to perform include: adjust line cost to achieve new 
routing paths, shut down network components or circuits, send 
messages to all network operators, and analyze errors and 
failures. 

o Bringing new devices, circuits, and users on line, 

o Gathering statistics on network use, traffic congestion, 
errors, and failures. 

You can delegate many of your responsibilities, but you are a key 
person in the success or failure of your network. You can ensure 
success by closely monitoring both the system and the manner in which 
your staff performs. 
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PART II 
DECnet OPERATION 



CHAPTER 3 
RUNNING DECnet-10 



3.1 DECnet STARTUP PROCEDURES 

To run DECnet on a DECSYSTEM-2020 running TOPS-10, you need only bring 
up the TOPS-10 monitor generated with DECnet, 

On the DECsystem-1090/1091/1095 with a DN20 DECnet front end, you must 
also load the communications front end with the MCB software. This 
normally occurs automatically when TOPS-10 is loaded. It can also be 
done manually any time after TOPS-10 is loaded. 



3.1.1 Automatic DECnet-10 Startup 

When TOPS-10 is loaded, the INITIA program automatically uses the 
FRCLIN functionality of the TOPS-10 monitor to process the commands in 
the file SYS : SYS JOB, INI . Following these commands, INITIA starts up 
major system programs, such as ORION, QUASAR and LPTSPL. 

The ORION program does an automatic TAKE of SYSTEM, CMD, which can then 
schedule a TAKE of NCP.CMD. (See the TOPS-10 Operator's Guide for 
information on GALAXY and OPR.) 
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Mount the SYSTEM disk pack on drive 0. Press the ENABLE rocker switch 
while pressing the DISK rocker switch on the console front end. 

RSX-20F VE15-31 10:30 24-May-85 

[SY0: redirected to DB0:] 

[DB0: mounted] 

KLI — VERSION VA15-50 RUNNING 

KLI — ENTER DIALOG [NO, YES, EXIT, BOOT] 

KLI> 

KLI — KL10 S/N: 2476., MODEL B, 60 HERTZ 

KLI — KL10 HARDWARE ENVIRONMENT: 

MCA25 CACHE PAGER 

EXTENDED ADDRESSING 

INTERNAL CHANNELS 

CACHE 

KLI — MICROCODE VERSION 2.0 [411] LOADED 
KLI — ALL CACHES ENABLED 

LOGICAL MEMORY CONFIGURATION. 

ADDRESS SIZE INT TYPE CONTROLLER 
00000000 1536K 4 DMA20 4 

KLI — CONFIGURATION FILE WRITTEN 
KLI — BOOTSTRAP LOADED AND STARTED 
BOOT V3(47) 

BOOT>DSKA: RL171B.EXE [1,4] 

[Loading from DSKA:RL171B. EXE [1 ,4] ] 

RL171B DEC10 Development 05-15-85 
Date: 15-JUN-85 
Time: 10:34 

Startup option: Q 

[Initializing CI network] 

%% Node N0VA(31) up at 10:34:57 

%% Node JUBLEE(2) up at 10:34:58 

[CCPWFD Waiting for file daemon to start] 

.LOGIN 1,2 

Figure 3-1: Startup Dialogue for TOPS-10 Version 7.03 DECnet-10 
Version 4.0 on a KL1090 System 
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RL171B DEC10 Development 10:34:59 CTY system 1026/1042 

Connected to Node KL1026(26) Line # 361 

.R OPSER 

[OPRPAF Processing auto command file] 

[KNLRLD Reloading NI-0 with microcode version 1(167)] 
%% Node SPIRIT(30) up at 10:34:58 
%% Node NEXT(27) up at 10:34:58 
%% Node COMET(70) up at 10:34:59 
%% Node CTCH22(22) up at 10:35:00 

[KNLRLD Reloading NI-1 with microcode version 1(167)] 
%%TTY STOMPER - Starting 

00:00:02 L 
00:00:00 L 



OPR 8 


1,2 


SL 


FAL 7 


1,2 


RN 


10:37:11(6) 







! [RP20 microcode %3(1) loaded on CPU0, RH20 550, DX20 on 14-Jun-85 
10:40:42] 

Figure 3-1: Startup Dialogue for TOPS-10 Version 7.03 DECnet-10 
Version 4.0 on a KL1090 System (Cent.) 



3.1.2 Manual Startup of DECsystem-1090/1091/1095 Communication Front 
End 

The TOPS-10 and the MCB Operating Systems may crash independently. 
When TOPS-10 fails, it attempts an automatic restart. If this restart 
is successful, the Network Management Program running under TOPS-10 
checks to see if the MCB system is running, if the MCB has also 
failed, it is loaded; if it has not failed, there is no action. 
Therefore, a manual startup is only required when normal automatic 
procedures fail. 

You can use the following sequence of commands if the DN20 
communications front end fails to come up when the TOPS-10 KL10 node 
comes up, or following a crash that is not followed by an autoload. 
Normally, the first step loads the front end. If the load fails, 
continue with the next sequence of commands. You must have system 
operator privileges to use these commands. 

Step 1: Type the following at your terminal: 

.R OPR 

OPR> ENTER NCP 

NCP>SET CIR DTE-0-1 STATE ON 

NCP>SET CIR DTE-0-1 SERVICE ENABLED 

NCP>LOAD NODE BOSTON 

The circuit identification, DTE-0-1 (DTE number 1 on CPU 0) , 
represents the DTE number connecting the MCB, node BOSTON, to 
the KL10. 
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Step 2: If the load falls, enter NCP and type an NCP SET NODE command 
for each of the required parameters. Inserting the values 
appropriate for your MCB DN20 node. Include as the last 
command, SET CIRCUIT DTE-0-1 SERVICE ENABLED. The value 
DTE-0-1 identifies the circuit over which the load occurs. 
Use the command file example in the next section to check 
format. "BOSTON" in the example is the name of the network 
front end. 

When loading the communications front end, you must provide 
values for the following parameters: 

Secondary Loader 

Tertiary Loader 

Service Circuit 

CPU = PDPll 

Load File 

Dump File 

Secondary Dumper 

Host 

Service Node Version 

You can now repeat: 

NCP>LOAD NODE BOSTON 



3.1.3 Manual Startup with Command Files 

It is helpful to use command files for procedures that are often 
repeated. You save unnecessary typing, avoid such errors as 
misspelling, and ensure against errors of omission. You will probably 
find it helpful to keep a set of command files in your own directory. 
The following is an example of a command file, BOSTON.CMD, for loading 
the front end named BOSTON: 

CLEAR EXECUTOR NODE 

SET NODE BOSTON CPU PDP-11 

SET NODE BOSTON SERVICE CIRCUIT DTE-0-1 

SET NODE BOSTON SERVICE NODE VERSION 

SET NODE BOSTON SECONDARY LOADER SYS : DTEMPS. SYS 

SET NODE BOSTON TERTIARY LOADER SYS :DTEMPT.SYS 

SET NODE BOSTON LOAD FILE SYS : BOSTON. SYS 

SET NODE BOSTON SECONDARY DUMPER SYS :DTEDMP. SYS 

SET NODE BOSTON DUMP FILE XPN: BOSTON. DMP 

SET NODE BOSTON HOST KL10 36 

SET CIR DTE-0-1 STATE ON 

SET CIR DTE-0-1 SERVICE ENABLED 

LOAD NODE BOSTON 

The above command set includes all information needed by the system 
for a manual load. However, when the system is brought up, several of 
the commands shown above are processed when the OPR.ATO file is 
executed. Normally, only the last two commands are required. 
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Assume the TOPS-10 system is running. Before using the network, you 
check the status of the communications front end and receive the 
following : 

NCP>SHOW NODE BOSTON STATUS<RET> 
NCP> 

9:24:09 NCP 

Request # 253; Show Node Status Completed 

Node State Active Delay Type Cost Hops Circuit 

Links 
7.129 (Boston) Reachable 1 Routing IV DTE-0-1 

Next node = 7.94 (PYTHON) 

If you do not receive output in a few minutes informing you that the 
load was successful, you can TAKE the file Boston.CMD after returning 
to monitor level. Input and output follow: 

.send all Will uisse a .CMD file to load front end in 5 minutes 

;;TTY51: - Will use a .CMD file to load front end in 5 minutes 

.R OPR 

OPR>DISABLE OUTPUT-DISPLAY (OF) ALL-MESSAGES<RET> 

OPR> 

9:59:51 — Output display for OPR modified — 

OPR> ENTER NCP<RET> 

NCP>TAKE BOSTON. CMD<RET> 



NCP>SHOW NODE BOSTON<RET> 

NCP> 

10:02:26 NCP 

Request # 271; Show Node Summary Completed 

Node State Active Delay Circuit Next Node 

Links 
7.129 (Boston) Reachable DTE-0-1 

NCP> 

The first command to the OPR program disables the display of all 
messages. This allows you to use the network facilities without 
interruption by numerous messages about such things as batch programs, 
tape mount requests and reports printed. You will receive all NCP 
responses and messages. 
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3.2 DECnet-10/PSI-10 RESTART PROCEDURES 

Section 3.2.1 describes the restart procedure for the ORION process, 
and Section 3.2,2 describes the restart procedure for NML. 



3.2.1 Restart Procedure for the ORION Process 

If the ORION process fails while you are entering NCP commands, the 
following message appears on your terminal: 

ORION not running 

You can restart the ORION process with the following command sequence 
from a [1,2] job terminal: 

.SYSTAT 

(get job number for ORION) 

• 

.ATTACH JOB-NUMBER [1,2] 

.HALT 

.GET SYS J ORION 

•CSTART 

.DETACH or attach to old job-number 

The ATTACH command re-attaches to the detached ORION program. The 
HALT command stops its execution, GET obtains a new copy of ORION. 
CSTART restarts execution, and DETACH detaches the job. 

If the restart is successful, the next step is to restart NML, the 
Network Management program containing the NCP module among other 
control modules (see Section 3.2.2). This is necessary because the 
new copy of ORION has no knowledge of NML' s location. When NML is 
loaded, the initialization routine identifies itself to ORION. If the 
communication front end has also crashed, you will also need to follow 
the procedures in Section 3.1.2. 



3.2.2 Restart Procedure for NML 

If the OPR program cannot communicate with NML, you receive the 
following message when you type an NCP command: 

NCP is not running 

This message can occur when ORION cannot communicate with NML (as when 
ORION is restarted without restarting NML). NML must be restarted. 

If you receive no response from an NCP command within a few minutes, 
enter the NCP command SHOW QUEUE. If NML refuses to respond to an NCP 
command, it may simply be busy loading a node. If there is no 
response to SHOW QUEUE, assume NML has stopped running. 
(Alternatively, you can use your normal procedure for determining the 
state of a program.) If NML is hung, then you should take a dump of 
NML and, if possible, note a description of the environment. 
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You can restart the NML program with the following command sequence 
from a [1,2] job terminal: 

.SYSTAT 

(get job number for NML), 

• 

.ATTACH JOB-NUMBER [1,2] 

.HALT 

.GET SYS: NML 

.CSTART 

.DETACH or attach to old job-number 

NML should be successfully restarted. 

When NML is restarted, the volatile data base is lost. Therefore, the 
procedure to restart NML includes TAKing the NCP.CMD file. The 
NCP.CMD file sets the node names and addresses (numbers) for the 
network and sets the values for the TOPS-10 Network Management 
volatile data base. Use the following commands: 

.R OPR 

OPR>TAKE SYS: NCP.CMD 

OPR>EXIT 

Once you restart NML, you are ready to continue network activity. 



3.2.3 Restart Procedure for X29SRV 

Use the following command sequence to restart the X29SRV program from 
a [1,2] job terminal: 

.SYSTAT 

(get job number for X29SRV) 

• 

.ATTACH JOB-NUMBER [1,2] 

.HALT 

.GET SYS:X29SRV 

.CSTART 

.DETACH or attach to old job-number 

X29SRV should be successfully restarted. 



3.2.4 Restart Procedure for PSITSB 

If the background process PSITSB is not running when you run the 
PSITST program, it displays a message similar to the following before 
halting: 

Encountered IPCF Error 

PSITST Partner Process Does Not Exist 

This message occurs when PSITST cannot communicate with PSITSB. 
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PSITSB must be restarted, and you can restart the program with the 
following command sequence from a [1,2] job terminal: 

.SYSTAT 

(get job number for PSITSB) 

• 

•ATTACH JOB-NUMBER [1,2] 

.HALT 

.GET SYS:PSITSB 

•CSTART 

.DETACH or attach old job-number 

PSITSB should be successfully restarted. 



3.3 CONTROLLING NODE, CIRCUIT, DTE, AND LINE STATE 

DECnet-10 does not support the setting of node state using the NCP 
command: 

' OFF 
SET NODE node id STATE ) ON 

SHUT 
RESTRICTED 

You can, however, control the state of the circuits connected to your 
node. Using the OFF parameter in the following NCP command, if there 
is no alternate path, causes the adjacent node to become UNREACHABLE. 
The circuit is nonoperational for network traffic. Therefore, when 
you use this command you must consider the position of the node to be 
set. If the node is a full-routing node, you can disrupt network 
traffic between several nodes. 



SET CIRCUIT cktid STATE 



(off) 



You may wish to set a circuit OFF if errors over the circuit become 
excessive, or if performance over the circuit becomes unacceptable. 

For the PSI option, you can control X.25 access with the following 
command : 



set module x25-protocol state 

"shut 



(off )| DTE dte-addressi 
< ON >| KNOWN DTES ( 



\ 

You may wish to turn the DTE off to terminate access to the PPSN. 
You can also control lines with the following command: 

!off) 
ON j 

Certain NCP commands require that a line be in the OFF state for 
execution of the command. 

With DECnet-10, you cannot set circuit or line state to SERVICE or 
CLEARED. 
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3.4 MONITORING NETWORK ACTIVITY 

DECnet-10 software continually monitors both static and dynamic 
characteristics and accumulates statistics for nodes, circuits, and 
lines. These statistics are available to you in two major ways: 

o with selected NCP commands 

o with the SPEAR program 

Considerable data is collected automatically. As a system manager, 
you are responsible for planning the "how" and "when" of collecting, 
organizing, and analyzing network data. If you take full advantage of 
the system's automatic monitoring facilities, the network will run 
more smoothly. Traffic patterns, hardware, and your site's needs can 
change in time. Parameters can be changed more efficiently when based 
on observations of actual statistics and characteristics. 

Periodic analysis also helps you prevent problems before they disrupt 
the network. For example, you can make desirable routing changes by 
adjusting the COST parameter before performance becomes unacceptable. 
Before and after comparisons can aid in evaluating the effect of new 
applications or additions to hardware. Observing traffic peaks may 
suggest helpful changes in scheduling. 

It is suggested that you run the SPEAR program daily (see Section 
3.4.2 for details) . The interval between the monitoring of other 
display types depends upon local activity and can only be decided 
after some experience with your network. Because counters are zeroed 
when the node where they are located goes down, some data may be lost 
at that time. How much is lost depends upon when data was last 
captured. Using command or control files saves time and effort. 

As a user with system operator privileges, you are responsible for 
providing the input according to plan and schedule. This requires a 
knowledge of the following: 

o the format of the appropriate NCP commands 

o an understanding of display types 

o familiarity with the specific items displayed according to 
entity, display type, and arguments and keywords used 

o an understanding of the SPEAR program 



3.4,1 NCP Commands for Network Monitoring - Local and Remote 

You can use NCP commands that display current attributes and 

statistics to monitor both the local node and remote nodes that have 

implemented the commands. To obtain output from a remote node, use 
either of the following procedures: 

Procedure 1 

NCP>SET EXECUTOR NODE MRVAX 

(Wait for Set Node Complete message) 
NCP>SHOW EXECUTOR CHARACTERISTICS 

(Output follows) 
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Procedure 2 

NCP>TELL MRVAX SH EX CHAR 

The NCP commands for monitoring the local node and its communications 
front end are described in Section 7.7. 

NOTE 

Using the NCP commands in this manual to communicate 
between DECnet-10 V4,0 nodes and other nodes on the 
network requires that the other nodes have implemented 
Network Management Version 3.0 or later. 



3.4.2 Using the SPEAR Program for Network Monitoring 

All network errors and significant events are written by the system 
into the file SYS: ERROR. SYS. The SPEAR program can be used to read 
these entries. You do not need privileges to run SPEAR. However, 
check any files that SPEAR uses for input or output. If accessing a 
file requires certain conditions, these should be met before you run 
the SPEAR program. 

When the prompt SPEAR> appears on the terminal, you type the mode of 
the SPEAR program you wish to run. You will probably find "RETRIEVE" 
and "SUMMARIZE" modes most useful for monitoring the network. SPEAR 
next asks for specific information. Each request is followed by a 
default answer in parentheses. To take the default, you press the 
RETURN key. 

SPEAR allows you to select only network-related events by specifying 
the "Selection type" as ERROR. You can then select one of the 
following network-related event types: 

NETWORK all network errors 

NI all NI related entries 

COMM all communication device entries 

The output of NETWORK can be restricted to specified event classes, 
for example: 

3 all class 3 events 

1,4 all class 1 and 4 events 

The output of NI can be restricted with these options: 

EBUS 

MBUS 

CRAM-PARITY 

CHANNEL-ERROR 

When SPEAR finishes selecting data as you have directed, SPEAR informs 

you that retrieval is complete. If you select the output default 

(DSK:RETRIE.RPT for the RETRIEVE mode and DSK:SUMMAR.RPT for SUMMARY 

mode), you can now type the report on your terminal, or print it. 

The SPEAR program creates the appropriate output file (RETRIE.RPT or 
SUMMAR.RPT) . The next time you run SPEAR you overwrite any existing 
file. Rename the previous file if you wish to save it. 
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The runtime for the same SPEAR report can vary from a few minutes to 
over an hour depending on filesize or system load. Runtime is greatly 
increased when you allow records to accumulate in the ERROR. SYS file. 
Runtime is somewhat longer when the system is busy. Use CTRL/T to 
check both the runtime and the fact that SPEAR is still running during 
the retrieval interval. 

When you have many thousands of records to search, runtime may become 
excessively long. Copying the ERROR, SYS file to tape every 30, 60, or 
90 days may not ensure a satisfactory runtime: fairly minor problems 
with network or system hardware or software can result in a 
proliferation of records sent to ERROR, SYS. As system manager, you or 
a delegated operator should monitor the file to prevent time-consuming 
SPEAR reports. Both the disk block count of the ERROR. SYS file (use 
the TOPS-10 DIRECT command) and the record sequence of retrieved 
entries will help you determine when you should copy the ERROR. SYS 
file to tape. 

You should keep all ERROR. SYS records on disk (current) or tape 
(historical) , (This complete copy is in addition to the regular 
system backup copy.) 

Example: 

The following example shows the SPEAR program, which selects a full 
report of network events in classes 3 and 4 occurring in the past two 
days : 

.R SPEAR<RET> 

Welcome to SPEAR for TOPS-10, Version 2(1137) 
Type "?•• for help. 

SPEAR> RETRIEVE<RET> 

RETRIEVE mode 



Event or packet file (SYS:ERROR.SYS) :<RET> 
Selection to be (INCLUDED) :<RET> 
Selection type (ALL) : ERROR<RET> 

Categroy (ALL): NETWORK<RET> 

Event class and type ( ALL) : 3,4<RET> 

Next category (FINISHED) :<RET> 
Time from (EARLIEST): -2<RET> 
Time to (LATEST) : <RET> 
Output mode (ASCII) :<RET> 

Report format (SHORT) : FULL<RET> 
Output to (DSK:RETRIE.RPT) :<RET> 



Type <cr> to confirm (/GO) :<RET> 

INFO - Retrieving selected entries from SYS:ERROR.SYS 

INFO - Retrieval Complete Total Entries = 100. 

SPEAR> EXIT<RET> 
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SPEAR allows you to select between two output formats SHORT and FULL. 
Because runtime depends primarily on search time for user-selected 
records, the short form saves little time and has certain 
disadvantages. If you need any of the following information, select 
the long form: 

o Detail on reason for error, if event was an error 

Example: "Line synchronization lost" 

for "circuit down, circuit fault" 

o Identification of the data link associated with an error 

Example: "Circuit = KDP-0-1" for "circuit 
down" and "circuit up" 

o For a "circuit up" event, the node at the remote end of the 
circuit 

Example: "Circuit = KDP-0-0 

NODE = Area. number 

The short form is useful because of its simpler format for locating 
specific events. Once found, you can then limit your "selected 
window" for the full report. 

For definitions of DECnet events, see Appendix C. 

For help in interpreting the SPEAR output, see the TOPS-10/TOPS-20 
SPEAR Reference Manual. 



3.5 DECNET-10 HOST SERVICES 

DECnet-10 can act as host node in performing the following services 
for unattended systems. 

o Downline loading of an unattended system: transferring a copy 
of an operating system file image from a TOPS-10 node to a 
target node. 

o Upline dump of memory from an unattended system: transferring 
a copy of a memory image from an unattended target node to 
your TOPS-10 host. 

o Connect to a remote console permitting a TOPS-10 terminal to 
act as the console for certain unattended systems, such as 
the DECserver-100, 

These operations are described in the following sections. 
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3.5.1 DOWNLINE LOADING 

DECnet-10 allows you to downline load an operating system image. 

Downline loading is the transferring of a copy of the system image 

file of a remote node's operating system from a TOPS-10 node to an 
unattended target node. For example, DECnet-10 lets you load an MCB 

image file from you DECnet-10 host node downline to a DN20 remote 

node. Downline loading can be initiated by a DECnet-10 operator or by 
the remote node. 

Following is a description of the nodes involved in the loading 
sequence. In the node descriptions, the command node and the executor 
node can be the same or different nodes, but cannot be the target 
node. See Figure 3-2. 

o Command Node. An operator-initiated downline load request 
originates at the command node. You can use either the NCP 
LOAD or TRIGGER command to initiate this request. 

o Executor Node. The executor node actually performs a 
downline load or trigger operation. It must be adjacent to 
the target node because the downline load uses circuit-level 
access. 



Target Node. The target node is the node that 
bootstap loaders and the system image file. 



receives the 




NCP>L0ADN0DETS1: 



KL1 = Command Node 
Executor Node 
Host Node 

TS1 = Target Node 



FE1:: 




TS1:: 


DN20 




Terminal 


MCB Node 




Server 



■NCP>TELL KL2:: LOAD NODE FE2: 



KL1:: 

TOPS-10 

Node 



:> 



KL2:: 

TOPS-10 

Node 



:<^ 



FE2 




TS2: 


DN20 




Terminal 


MCB Node 




Server 



KL1 = Command Node 

KL2 = Executor Node 
Host Node 

FE2 = Target Node 



MR-S-4461-86 



Figure 3-2: Types of Nodes by Network Function 
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Downline loading is initiated in one of two ways: 

o Target-initiated, The target node initiates the operation by 
triggering its bootstrap ROM and sending a program load 
request to the executor node. 

o Operator-initiated. An operator on the executor node 
initiates the operation with the NCP LOAD or TRIGGER command. 



3.5.1.1 Target-initiated Downline Loading - If the load is 
target-initiated and the circuit is a non-Ethernet circuit, the 
Routing layer process detects Low Level Maintenance Operation Protocol 
(LLMOP) messages coming over the circuit and calls the Data Link 
Watcher (DLW) . 

If the target on an Ethernet circuit does not have a specific host 
node from which to request a program load (for example, if the 
target's host node crashes, or if the load is initiated by means of 
the BOOT button on the target), the target proceeds as follows: 

1, The target node sends a program load request message to the 
Ethernet load assistance multicast address AB-00-00-01-00-00 . 
This message is a request for any node on that Ethernet to 
perform the load, 

2, The nodes on the Ethernet whose Ethernet circuits are enabled 
for service operations check their own node databases for a 
remote node entry whose Ethernet hardware address matches 
that of the target node. This determines if they can 
downline load the target. If so, they send to the target the 
secondary loader (if the target is requesting the secondary 
loader), or a message volunteering to do the load (if the 
target is requesting the tertiary loader or operating 
system) . 

3, The target chooses the node responding first to continue the 
loading sequence. It does not send a message to any other 
node. The loading sequence continues normally from there. 



3,5«1.2 Operator-initiated Downline Loading - An operator- initiated 
load uses NCP directly to perform the load operation. The target 
node's primary bootstrap may or may not have to be triggered depending 
on the state of the target. The target node is triggered primarily to 
put it into a known state and to force it to supply program request 
information. 

Use the NCP LOAD or TRIGGER command to perform an operator- initiated 

downline load. The TRIGGER command allows you to directly trigger the 

remote node's bootstrap ROM (if the device supports this), which 

causes the target node to load itself in whatever manner the primary 
loader is programmed to operate. The programs to be loaded may come 

from a disk file local to the target node, another adjacent node, or 
the executor node. 

Note that the TRIGGER command may or may not initiate a downline load. 
One of the functions of this command is to simulate the operation that 
occurs when the BOOT button on the target node is pushed. A bootstrap 
operation from a local disk may result. 
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When you use the LOAD command, the executor node proceeds with the 
load operation according to the options specified in the initial load 
request. Any required information that has been defaulted is obtained 
from the host node's volatile database. With this information, the 
executor is thereby able to control the load sequence. 

Chapter 7 describes the TRIGGER and LOAD commands. 



3.5.2 LOAD Sequence 

The first program to run at the target node is the primary loader. 
Typically, this program is either executed directly from the target 
node's bootstrap ROM, or it is in the microcode of the load device 
(DMC, DMR, DMP, DMV, NI) . Once the target node's primary loader is 
triggered, the target node sends a REQUEST PROGRAM LOAD message to the 
executor node requesting a program load. Usually, the primary loader 
requests a secondary loader program, which, in turn, may request a 
tertiary loader. The final program to be loaded is the operating 
software. In this sequence, each program requests the next one until 
the operating software is loaded. 

The secondary loader is small (400-600 bytes) and is always sent as a 
single MEMORY LOAD WITH TRANSFER message. The secondary loader is 
always loaded into the lower 36K words of memory and operates without 
memory management. The secondary loader requests the tertiary loader, 
which is sent in multiple MEMORY LOAD messages followed by a MEMORY 
LOAD WITH TRANSFER ADDRESS message. 

The tertiary loader is much larger (1-3K bytes) and uses memory 
management to relocate itself to the top of memory before requesting 
the operating system. For this reason any operating system to be 
loaded must not use the top 3K bytes of memory or the tertiary loader 
would be forced to overwrite itself and the load would not be 
successful. The operating system is sent in multiple MEMORY LOAD 
messages followed by a PARAMETER LOAD WITH TRANSFER ADDRESS message, 
which supplies the start address of the image just loaded and contains 
extra values for the node identification and the host identification. 



3.5.3 Downline Load Requirements 

Before attempting a downline load operation, you must ensure that the 
nodes, lines, and circuits involved in the downline load meet the 
following requirements: 

o The target node must be connected directly to the executor 
node. This is necessary because the executor node uses 
circuit-level access to load the target system; no routing 
information is used. 

o The proper bootstrap must be present at the target node. 
This bootstrap must be capable of recognizing TRIGGER 
messages if the node is to be operator-initiated downline 
loaded or, be able to send program requests if the load is 
target- initiated. 

o The physical hardware devices must be set up correctly to 
support the load. 

o The executor node must have access to the load files. The 
location of the files can either be specified in the load 
request or defaulted by the remote node database. 
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3.5.3.1 Downline Load Bootstraps - The downline load sequence is 
started by a primary loader. This primary loader is contained in the 
target node's bootstrap ROM or in the microcode of the target node's 
load device. In either case, you must ensure that you have the proper 
ROM support for the downline load to be initiated. Following is a 
list of the types of bootstrap supported by each device: 

o Power-on boot. This device can be used when the bootstrap 
will be invoked by a power-on condition. 

o Remote trigger detect boot. This device can be used for 
operator-initiated downline loads because it responds to the 
TRIGGER message, 

o Console boot. When a power-on boot cannot be used, the 
target's console can be used to start the downline load 
sequence. If this is the only type of boot supported, the 
target system cannot operate entirely unattended. 



3.5.3.2 Setting Up the Downline Load Devices - If the sequence is to 
function correctly, the devices involved in the downline load 
operation must be configured properly. In all cases the host node 
device is set up in a normal manner (see the Operations Manual for the 
device being used) . 

Whenever possible you should conduct a loopback test to verify the 
operation of the Ethernet target's (and the host's) downline load 
device before trying the downline load. 



3.5.3.3 Set Up the Host Circuit - The host circuit must be in the ON 
or SERVICE state; an Ethernet circuit must be in the ON state. For 
example, the following command readies circuit DMC-0 for downline 
loading an adjacent node: 

NCP>SET CIRCUIT DMC-0 SERVICE ENABLED 
NCP>SET CIRCUIT DMC-0 STATE ON 



3.5.3,4 Establish Default Information - The most convenient method of 
downline loading is to set up default information in the volatile 
database. You can use the SET NODE command to establish default 
information for the target node in the volatile database. For 
example, 

NCP>SET NODE 1.124 NAME KL2001 



3.5.3.5 Trigger the Bootstrap Mechanism - Use the NCP TRIGGER NODE or 
TRIGGER VIA command to trigger the bootstrap mechanism of a target 
node, which causes the node to request a downline load. Because the 
system that is being booted is not necessarily a fully functional 
network node, the operation must be performed over a specified 
circuit. For example, 

NCP>TRIGGER NODE JUPITE VIA DMC-0 



3-16 



RUNNING DECnet-10 



NOTE 



If you use the TRIGGER NODE command and do not specify 
a loading circuit, the executor node obtains the 
circuit identification associated with the target node 
from its volatile database. 

If you use the TRIGGER VIA command, which Indicates 
the loading circuit but not the node identification, 
the executor node uses the default target node 
identification in its remote database. 



3.5.3.6 Overriding Default Parameters - if you choose to override the 
default parameters that were set up in the remote node' s database 
using NCP SET NODE command, you can change the following aspects of 
the TRIGGER sequence. (See Chapter 7 for a detailed description of 
the following parameters.) 

o The physical address of the target node: 

PHYSICAL ADDRESS ethernet-address 

o The service password needed to trigger the target's load 
device: 

SERVICE PASSWORD password 

o (For TRIGGER NODE only) The service circuit used for the 
downline load: 

VIA circuit-id 

Once the target node is triggered, it will then load itself in 
whatever manner its primary loader is programmed to operate. The 
target node could request a downline load from either the executor 
node that just triggered it or another adjacent node, or the target 
node could load itself from its own mass storage device. 



3.5.3.7 Load the Target Node - Use the NCP LOAD NODE or LOAD VIA 
commands to load the software downline to a target node. The LOAD 
NODE command requires the identification of the service circuit over 
which to perform the load operation. If you do not explicitly specify 
a service circuit in this command, the executor node uses the SERVICE 
CIRCUIT from the remote node database entry for the target node. Use 
the SET NODE command to enter the SERVICE CIRCUIT in the database. 

Alternatively, you can use the LOAD VIA command to specify the circuit 
over which to perform the downline load. For example, to load using 
circuit DMC-0 connected to the executor node, issue the command: 

NCP > LOAD VIA DMC-0 



3.5.3.8 Procedure if the LOAD Fails - If the load fails, enter NCP 
and define default parameters for downline loading. Each target 
system to be loaded has a separate set of defaults. Use the SET NODE 
command to set up the database. To remove node parameters from the 
database, use the CLEAR NODE command. 
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NOTE 



Some parameters have a different keyword associated 
with them depending on whether the parameter is being 
specified in the SET NODE command or in one of the 
LOAD or TRIGGER commands. 

The downline load parameters that you can define for each target in 
the database include: 

o A service circuit parameter for the executor node: 

SERVICE CIRCUIT circuit-id 

o Parameters that pertain to the target node: 

NODE node- id 

NAME node-name 

SERVICE NODE VERSION phase 

SERVICE DEVICE device-type 

SERVICE PASSWORD password 

HARDWARE ADDRESS eth-address (Ethernet nodes only) 

HOST node- id 

o Parameters that specify load files: 

CONSOLE LOAD FILE file 
CONSOLE SECONDARY LOADER file 
LOAD FILE file 
SECONDARY LOADER file 
TERTIARY LOADER file 

DIAGNOSTIC FILE file (Ethernet Communications Server 

Only) 

All these parameters are described in Chapter 7, 

NOTE 

For a downline load request to be successful, you must 
specify at least the SERVICE CIRCUIT, NODE, NAME, and 
LOAD PILE parameters either in the LOAD command or by 
previously defined defaults. For Ethernet nodes, the 
HARDWARE or PHYSICAL ADDRESS must also be Specified. 

When the appropriate values have been defined for the parameters 
listed above, you can re-enter the LOAD command, for example: 

NCP>LOAD NODE LAT100 



3.5.3.9 Host Identification - At the end of the load sequence, the 
target receives a message with the name of the host and places that 
name in its volatile database. The target can then use the HOST 
node-id for downline task loading applications. The host may be the 
executor node or any other reachable node except for the target 
itself. Use the SET NODE command to specify a default host node where 
the target will find the files used to load tasks downline. For 
example, the command below sets node BANGOR' s host to node NYC: 

NCP>SET NODE BANGOR HOST NYC 

You can override any default information by using the HOST parameter 
for the LOAD command , 
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3.5.3.10 Load File Identification ~ The load files are those files to 
be loaded downline to the target node. These files may consist of a 
secondary loader, a tertiary loader, and an operating system image. 
If the node is a communications server with an operator console, the 
files may also consist of a console loader and a console secondary 
loader. You can specify default load file names in the volatile 
database with the SET NODE command. 
SYStnodename.SYS. DECnet-10 does not 
downline loading or dumping. 



Load files default to 
support remote files for 



The following sequence of NCP commands loads the 
over a DTE circuit: 



target node AURORA 



NCP>SET EXECUTOR NODE BOSTON 

NCP>SET CIRCUIT DTE-0-1 STATE ON 

NCP > LOAD NODE AURORA FROM SYS: AURORA. SYS 

If the secondary and tertiary file names are not included in the LOAD 
command or as entries in the volatile database for the target node, 
the load will not occur. 

The default secondary and tertiary loader files for DECnet-10 are the 
following : 



Device 
Type 



Secondary 
Loader 



Tertiary 
Loader 



DTE 
QNA 
UNA 



DTEMPS.SYS 
SECQNA.SYS 
SECUNA.SYS 



DTEMPT.SYS 
TERQNA.SYS 
TERUNA.SYS 



If you include the secondary and tertiary file names as entries in the 
volatile database for the target node, they can override the default 
loader files described above. By using the SET NODE command, you can 
select your own special load files for a particular target node. If 
you do not specify the load files, you can change the service device 
type at the target node without changing the target node's database 
entry at the executor node. 

The system image file entry in the host node's volatile database 
serves as the default file name for the operating system to be 
downline loaded. This file name is required when the target node is 
to be loaded, but it can be supplied by the LOAD command. 



3.5.3.11 Software Type - Along with identifying load files, you can 
specify the file types to be used for the initial load. For example, 
if the target node is already running a secondary loader program, you 
may only want to load the tertiary loader and operating system 
downline. To do this, you use the SOFTWARE TYPE parameter with the 
LOAD command. For example, to load the tertiary loader file, which in 
turn would load the operating system image, use the following command: 

NCP>LOAD NODE BANGOR SOFTWARE TYPE TERTIARY-LOADER 

Use the SET NODE command to specify default software type information 
for the target node entry in the volatile database. If no software 
type information is specified in the volatile database, the default 
type is the secondary loader. 
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3.5.3.12 CPU and Software Identification - The software 
identification is the default program name of the operating system to 
be loaded downline. Use the SOFTWARE IDENTIFICATION parameter to 
specify a software-id of up to 16 alphanumeric characters. For 
example, the following command specifies the default operating system 
to be loaded downline: 

NCP>SET NODE BANGOR SOFTWARE IDENTIFICATION SYS:RSX11S. SYS 



3.5.3.13 Service Device Identification - The service device is the 
controller on the target node end of a service circuit. The service 
device handles downline loading in a variety of ways, depending on the 
device used. In particular, this device influences the type of files 
suitable for downline loading. Default load file names are selected 
according to the service device for the target node. 

The SERVICE DEVICE parameter identifies the default secondary and 
tertiary loaders for the load operation. This parameter is required 
for any downline load if the secondary and tertiary load files are not 
specified in the volatile database of the target node. SERVICE DEVICE 
is also required if the program load requests from the target node do 
not specify the secondary and tertiary load file names. Use the SET 
NODE command to specify the service device type in the volatile 
database. For example, the command below identifies the service 
device as an NI device controller. 

NCP>SET NODE BANGOR SERVICE DEVICE UNA-0 

By using the SERVICE DEVICE parameter for the LOAD command, you can 
override the default service information. 



3.5.3.14 Service Circuit Identification - In terms of the executor, 
the service circuit is a circuit connecting the executor node with an 
adjacent target node. When you issue the LOAD and TRIGGER commands, 
you must specify or default to a circuit over which the load operation 
is to take place. Use the VIA parameter to explicitly identify the 
circuit when issuing those commands. If specifying an Ethernet 
circuit in the LOAD VIA command, you must include the PHYSICAL ADDRESS 
parameter in the command. 

If you do not specify a circuit, this information defaults to the 
circuit specified in the target node's volatile database. To set a 
service circuit in the volatile database, use the SET NODE command. 



3.5. 3.15 Service Passwords - When defining nodes for downline loading 
in the local volatile database, the system manager can specify a 
default service password. This password may be required to trigger 
the primary bootstrap mechanism on the target node. If a user issues 
a LOAD or TRIGGER command without a service password, then this 
default parameter will be used if the target node requires one. To 
set a service password in the volatile database, use the SET NODE 
command. This password must be a hexadecimal number in the range to 
FFFFFFFFFFFFFFFF. 

For example, to load node BANGOR use the following commands: 

NCP>SET NODE BANGOR SERVICE PASSWORD FEFEFEFE 
NCP>LOAD NODE BANGOR 
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3.5.3.16 Diagnostic File - Once the target node is loaded downline, 
it can request diagnostics. Use the DIAGNOSTIC FILE parameter in the 
SET NODE command to identify (in the volatile database) the 
diagnostics file that the target node can read. 



3.5.4 Downline Loading a Communications Server 

The following example show the procedure for downline loading a 
terminal server called LAT4 over the Ethernet. 

NCP>CLEAR NODE 13.204 NAME 

NCP>CLEAR NODE 13.204 ALL 

NCP>SET NODE 13.204 NAME LAT4 

NCP>SET NODE LAT4 SERVICE CIRCUIT ETH-0 

NCP>SET NODE LAT4 SECONDARY LOADER SYS: PLUT02.SYS 

NCP>SET NODE LAT4 TERTIARY LOADER SYS:PLUT03.SYS 

NCP>SET NODE LAT4 LOAD FILE SYStPLATOT.SYS 

NCP>SET NODE LAT4 DUMP FILE XPNsLAT4.DMP 

NCP>SET NODE LAT4 SERVICE PASSWORD 

NCP>SET NODE LAT4 HARDWARE ADDRESS AA0003012F99 

NCP>SET NODE LAT4 HOST ETHER 

NCP>SET CIRCUIT ETH-0 SERVICE ENABLED 

NCP>LOAD NODE LAT4 



3.5.5 Downline Loading the DN20 

A manual load of the DN20 may be indicated in the following 
circumstances: 

o The DN20 was not powered up when the KL10 was loaded 

o The DN20 became "UNREACHABLE" after being loaded and must be 
reloaded 

If one of the above conditions exists, TOPS-10 should execute an 
automatic reload of the system. If the automatic reload does not 
occur, try to load by using the appropriate command file (see Section 
3.1.3) or by typing the necessary NCP commands on your terminal (see 
Section 3.1.2) . 

The following example shows the procedure for downline loading a DN20 
communications front end: 

NCP>SET NODE D2102A CPU PDP-11 

NCP>SET NODE D2102A SERVICE CIRCUIT DTE-0-1 

NCP>SET NODE D2102A SERVICE NODE VERSION 

NCP>SET NODE D2102A SECONDARY LOADER SYS:DTEMPS.SYS 

NCP>SET NODE D2102A TERTIARY LOADER SYS:DTEMPT.SYS 

NCP>SET NODE D2102A LOAD FILE SYS:D2102A.SYS 

NCP>SET NODE D2102A DUMP FILE XPN:D2102A.DMP 

NCP>SET NODE D2102A SECONDARY DUMPER SYS:DTEDMP.SYS 

NCP>SET NODE D2102A HOST KL2102 

NCP>SET CIRCUIT DTE-0-1 STATE ON 

NCP>SET CIRCUIT DTE-0-1 SERVICE ENABLED 

Note that since the DN20 is a Phase III node, this procedure includes 
the command : 

SET NODE 2102A SERVICE NODE VERSION 

which identifies the target as a Phase III node. 

3-21 



RUNNING DECnet-10 

3.5.6 UPLINE DUMPING 

You can include certain SET NODE parameters in the volatile database 
that allow an adjacent unattended node to dump its memory into a file 
on your TOPS-10 system. This procedure is called upline dumping, and 
it is a valuable tool for crash analysis. Programmers can analyze the 
dump file and determine why the unattended system failed. When an 
unattended system detects an impending system failure, that system 
requests an upline dump; for example, the DN20 may request an upline 
memory dump to the KL10 system. 

For upline dump operations, the local KL10 node is referred to as the 
executor and the adjacent unattended node as the subordinate. A 
subordinate can be a DN20 or an Ethernet Communications Server. 



3.5.6.1 Upline Dump Procedures - This section describes the 
procedures for an upline dump initiated by a subordinate node, DECnet 
uses the maintenance operation protocol (MOP) to perform an upline 
dump operation. MOP is a subset of the DIGITAL Data Communications 
Message Protocol (DDCMP) , which sends messages used for circuit 
testing, triggering, downline loading, and upline dumping. See the 
Maintenance Operation Protocol Functional Specification for a more 
complete discussion. 

There are four steps involved in the upline dump process. The actual 
dump takes place by repeating step 3. 

1. When a subordinate node senses a system failure, it sends a 
memory dump request to the KL10 host node. On the Ethernet, 
it sends requests to a dump assistance multicast address if 
an Ethernet host is not available. The request is a MOP 
request dump service message. This message might contain 
information about the subordinate's memory size (DUMP COUNT) 
and the upline dump device type at the subordinate. 

2. If the message from the subordinate includes a DUMP COUNT 
value, the host node uses it. Otherwise, the host node 
checks the subordinate node's entry in its volatile database 
for the DUMP COUNT, the target address from which to start 
dumping (DUMP ADDRESS) and the file where the memory will be 
stored for the subordinate. (If no entry exists for DUMP 
ADDRESS, the value defaults to 0. If no entry exists for 
DUMP FILE, the file defaults to XPN:node-name.DMP.) The host 
node, which can now be considered the executor, sends a MOP 
request memory dump message to the subordinate with the 
starting address and the buffer size values. 

3. Using the values it received from the executor, the 
subordinate returns the requested block of memory in a MOP 
memory dump data message. The executor receives the block of 
dump data, places it in the DUMP FILE, increments the DUMP 
ADDRESS by the number of locations sent, and sends another 
request memory dump message to the subordinate. This 
sequence is repeated until the amount of memory dumped 
matches the DUMP COUNT value. The executor then sends a MOP 
Dump Complete message to the target. 

4. Once the upline dump is completed, the executor node 
automatically attempts to downline load the subordinate 
system, it initiates the downline load by sending a TRIGGER 
message to the subordinate. 
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If the target node is on an Ethernet circuit, the target will attempt 
to perforin an upline dump to the node that originally loaded it 
downline. If that node is not available, the target node proceeds as 
follows: 

1. The target node sends a memory dump request to the Ethernet 
dump assistance multicast address AB-00-00-01-00-00. This 
message is a request for any node on the Ethernet to receive 
an upline memory dump. 

2. The nodes on the Ethernet whose circuits are enabled to 
perform service functions check their own databases to 
determine if they can accept an upline dump. If so, they 
respond to the target node. The target chooses the node 
responding first to continue the dumping sequence. The 
target does not send a message to any other node. The 
loading sequence continues normally from there. Note, 
however, that you may have to look for event 0.3 in the event 
logs for all nodes on the Ethernet to determine which node 
received the dump. 



3.5.6*2 Upline Dump Requirements - Prior to attempting an upline dump 
operation, you must ensure that the nodes, lines, and circuits meet 
the following requirements: 

1. The subordinate node must be directly connected to the 
executor node by a physical line. The executor node provides 
the line- and circuit-level access. 

2. The subordinate node must be capable of requesting the upline 
dump when it detects a system failure. If the dumping 
program does not exist on the subordinate, upline dumping 
cannot occur. 

3. The circuit involved in the dump operation must be enabled to 
perform service functions. It must also be in the ON state. 
For example, the following command readies circuit ETH-0 for 
upline dumping: 

NCP>SET CIRCUIT ETH-0 SERVICE ENABLED 
NCP>SET CIRCUIT ETH-0 STATE ON 

4. If the subordinate does not supply the DUMP FILE name; the 
executor must have this entry in its volatile database. 



3.5.6.3 Manual Upline Dump of the DN20 MCE - This section applies 
only to a MCB node adjacent to the KL10 host node. If the DN20 
crashes. Network Management software in the KL10 node senses that 
communication has been lost. Using dump-related parameter values for 
the DN20, the KL10 initiates a dump of the entire contents of the 
DN20's memory. This is automatic and normally occurs whenever 
communication between the TOPS-10 and the DN20 is lost. A reload 
normally follows the dump. 
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If it appears that the automatic dump/ reload is not going to occur 
(you do not get a load node complete message) , type an NCP SHOW QUEUE 
command. If there is no response to SHOW QUEUE, wait 30 seconds. 
(NCP cannot respond if it is in the process of dumping or loading.) 
Because the system load has a significant effect on execution time, 
you must judge wait-time by experience. 

If the DN20 is still not online, use the following command with the 
TOPS-10 KL as executor: 

NCP>SET CIRCUIT DTE-X-y SERVICE ENABLED 

where DTE-x-y identifies the SERVICE CIRCUIT over which the dump and 
load is to occur. 

You should eventually receive the load node complete message. If you 
don't receive the message, follow the procedures in Section 3.2,2 
(Restart Procedure for NML) . 



3.5,7 Connecting to a Remote Console 

DECnet-10 allows you to set up a logical connection between your 
TOPS-10 node and the console interface on certain unattended nodes, in 
effect permitting your terminal to act as the console for the remote 
system. For example, your terminal can act as the console for the 
DIGITAL Ethernet Communications Server (DECSA) hardware and its 
resident software, such as the DECnet Router software and the 
DECserver-100 Terminal Server. 

You can set up the logical connection to the console using the RMTCON 
facility. Both your host node and the target node (that is, the 
server node) must be on the same Ethernet. 

For more information on using RMTCON, type HELP at the RMTCON> prompt. 



3.6 TESTING THE NETWORK 

In addition to using the SPEAR program, you can use loopback testing 
and CHKll output as diagnostic tools to help determine whether the 
network is operating properly. These tests let you exercise network 
software and hardware by sending data through various network 
components and then returning that data to its source. After you have 
started DECnet-10, you may want to run some of these tests. CHKll 
output goes to SYS: ERROR. SYS. 



3.6,1 Using Loopback Tests 

DECnet-10 supports the NCP commands LOOP NODE and LOOP CIRCUIT. The 
LOOP LINE command is supported in the MCB for DECnet-10 PSI (LAPB 
lines only) . 

LOOP NODE exercises all DECnet layers in the DN20 and in the remote 
node when the loop is executed from a local node to remote node. 
Normal network activity continues with the appropriate protocols and 
with the normal updating of counters at each level. The LOOP CIRCUIT 
command, however, does not exercise all levels. It uses the MOP 
Protocol, and does not result in the incrementing of counters. 



3-24 



RUNNING DECnet-10 

You can use the LOOP NODE command to loop messages at a running remote 
node, at the device controller, or at a turnaround connector (loopback 
connector) on a physical line. The following examples demonstrate 
these three uses. The first example is best executed first: if it 
succeeds there is no need to test further. 

The LOOP NODE procedure that loops at a remote node requires that the 
remote node is running Network Management V3.0 or later. 

Example 1: 

LOOP NODE •- Local to Remote 

.R OPR<RET> 

OPR>ENTER NCP<RET> 

NCP>SHOW NODE D1037A<RET> 

NCP> 

10:27:04 NCP 

Request # 263; Show Node Summary Completed 

Node State Active Delay Circuit Next Node 

Links 
123 (D1037A) Reachable 1 DTE-0-1 
NCP>LOOP NODE D1037A COUNT 10 LENGTH 20<RET> 
NCP> 
10:27:46 NCP 

Request # 264 Accepted 
10:27:53 NCP 

Request # 264; Loop Node Completed 
NCP>EXIT<RET> 

Example 2: 

LOOP NODE - Using Device Controllers DMR and KDP (MCB only) 

In this example, a circuit is established over which the messages will 
travel, a loop name is established, and the controller is set to 
loopback mode. This example is for the MCB only. 

For DMR: (system output not shown) 

NCP>SET EXECUTOR NODE D1036A USER OPERATOR PASSWORD SECRET 

NCP>SET CIRCUIT DMR-0 STATE OFF 

NCP>SET LINE DMR-0 STATE OFF 

NCP>SET NODE FOO:: CIRCUIT DMR-0 

NCP>SET LINE DMR-0 CONTROLLER LOOPBACK 

NCP>SHOW LINE DMR-0 CHARACTERISTICS 

NCP>SHOW CIRCUIT DMR-0 STATUS 

NCP>SET LINE DMR-0 STATE ON 

NCP>SET CIRCUIT DMR-0 STATE ON 

NCP>LOOP NODE FOO:: COUNT 10 LENGTH 20 

NCP> 

*** This controller-loopback test is completed. *** 
*** Procedure for restoring normal network *** 
*** conditions follow. *** 

NCP>SET CIRCUIT DMR-0 STATE OFF 
NCP>SET LINE DMR-0 STATE OFF 
NCP>SET LINE DMR-0 CONTROLLER NORMAL 
NCP>CLEAR NODE FOO:: CIRCUIT 
NCP>SET LINE DMR-0 STATE ON 
NCP>SET CIRCUIT DMR-0 STATE ON 
NCP>SHOW LINE DMR-0 CHARACTERISTICS 
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NCP>SHOW LINE DMR-0 STATUS 
NCP>SHOW CIRCUIT DMR-0 STATUS 
NCP>CLEAR EXECUTOR NODE 

For KDP (MCB only) : 

This test differs from the test using the DMR in just one respect. 
For the KDP controller loopback, you must set the CLOCK to INTERNAL. 
This test is for the MCB only. (System output not shown) 

NCP>SET EXECUTOR NODE D1036A USER OPERATOR PASS SECRET 

NCP>SET CIRCUIT KDP-0-0 STATE OFF 

NCP>SET LINE KDP-0-0 STATE OFF 

NCP>SET LINE KDP-0-0 CONTROLLER LOOPBACK 

NCP>SET LINE KDP-0-0 CLOCK INTERNAL 

NCP>SET NODE FOO: : CIRCUIT KDP-0-0 

NCP>SHOW LINE KDP-0-0 CHARAC 

NCP>SET LINE KDP-0-0 STATE ON 

NCP>SET CIRCUIT KDP-0-0 STATE ON 

NCP>LOOP NODE FOO:: COUNT 10 LENGTH 20 

*** This controller-loopback test is completed. *** 
*** Procedure for restoring normal network *** 
*** conditions follow. *** 

NCP>SET LINE KDP-0-0 STATE OFF 
NCP>SET CIRCUIT KDP-0-0 STATE OFF 
NCP>CLEAR NODE FOO:: CIRCUIT 
NCP>SET LIN KDP-0-0 CONTROLLER NORMAL 
NCP>SET LINE KDP-0-0 CLOCK EXTERNAL 
NCP>SET LINE KDP-0-0 STATE ON 
NCP>SHO LIN KDP-0-0 CHARAC 
NCP>SET CIRCUIT KDP-0-0 STATE ON 
NCP>CLEAR EXECUTOR NODE 

Example 3: 

LOOP NODE - Loopback Connector on Cable 

This procedure is similar, but not identical, to controller loopback. 
The LOOP NODE command is used again to do the testing. Messages are 
looped back at a manually installed (and later removed) loopback 
connector. Thus, the controller is not placed in loopback mode. 

For DMR: (system output not shown) 

NCP>SET EXECUTOR NODE D1036A PASS SECRET USER OPERATOR 
NCP>SET CIRCUIT DMR-0 STATE OFF 

*** Install loopback connector *** 

NCP>SET NODE FOO:: CIRCUIT DMR-0 
NCP>SET CIRCUIT DMR-0 STATE ON 
NCP>LOOP NODE FOO:: COUNT 10 LENGTH 20 
NCP>CLEAR NODE FOO:: CIRCUIT 
NCP>SET CIRCUIT DMR-0 STATE OFF 

*** Remove loopback connector *** 
*** Restore network connection *** 

NCP>SET CIRCUIT DMR-0 STATE OFF 
NCP>CLEAR EXECUTOR NODE 
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For KDP (MCB only) : 

This procedure is similar to that for the DMR with a loopback 
connector. However, the KDP test requires that you set the line 
parameter CLOCK to INTERNAL. Hence, you turn both line and circuit 
OFF before and ON after making parameter changes SET LINE and SET 
NODE. This procedure is for the MCB only. (System output not shown) 

NCP>SET EXECUTOR NODE D1036A PASS SECRET USER OPERATOR 
NCP>SET CIRCUIT KDP-0-0 STATE OFF 
NCP>SET LINE KDP-0-0 STATE OFF 
NCP>SET LIN KDP-0-0 CLOCK INTERNAL 

*** Install loopback connector *** 

NCP>SET NODE FOO: : CIRCUIT KDP-0-0 
NCP>SET LIN KDP-0-0 STATE ON 
NCP>SET CIRCUIT KDP-0-0 STATE ON 
NCP>LOOP NODE FOO:: COUNT 10 LENGTH 20 
NCP>SET LIN KDP-0-0 STATE OFF 
NCP>SET CIRCUIT KDP-0-0 STATE OFF 

*** Remove loopback connector *** 
*** Restore network connection *** 

NCP>CLEAR NODE FOO:: CIRCUIT 
NCP>SET LIN KDP-0-0 CLOCK EXTERNAL 
NCP>SET LIN KDP-0-0 STATE ON 
NCP>SET CIRCUIT KDP-0-0 STATE ON 
NCP>CLEAR EXECUTOR NODE 

You can also use the LOOP CIRCUIT command from your local node to an 
adjacent remote node, using controller loopback, and with a loopback 
connector. The procedure would follow the appropriate node loopback 
procedure except that the loopback node, FOO, would not be set. (The 
node loopback procedure is recommended.) 

Example 4: 

LOOP LINE - Loopback Connector on Cable fPSI option only) 

This procedure is for the KDP only. (System output not shown) 

NCP>SET EXECUTOR NODE MRX25 
NCP>SET LINE KDP-0-0 STATE OFF 

*** Install loopback connector *** 

NCP>SET LINE KDP-0-0 CLOCK INTERNAL 

NCP>SET LINE KDP-0-0 SERVICE ENABLED 

NCP>SET LINE KDP-0-0 STATE ON 

NCP>LOOP LINE KDP-0-0 COUNT 120 WITH MIXED LENGTH 10 

*** This controller-loopback test is completed. *** 
*** Procedure for restoring normal network *** 
*** conditions follow. *** 

NCP>SET LINE KDP-0-0 STATE OFF 

*** Remove the loopback connector. *** 
*** Restore connection to PPSN modem *** 

NCP>SET LINE KDP-0-0 CLOCK EXTERNAL 
NCP>SET LINE KDP-0-0 SERVICE DISABLED 
NCP>SET LINE KDP-0-0 STATE ON 

3-27 



RUNNING DECnet-10 

3.6.2 Circuit Level Loopback Testing 

In DECnet-10, circuit-level loopback testing is supported only for 
Ethernet circuits. The Network Management layer accesses the Data 
Link layer directly, thus bypassing intermediate DECnet layers. One 
advantage of the Ethernet loopback test is that it can be performed 
concurrently with other DECnet operations on the circuit. 

DECnet~10 supports two types of looping on the Ethernet. You can loop 
to the multicast address, or to a specific remote node. 



3.6.2.1 Looping to a Multicast Address - To test the NIA20 hardware 
use the LOOP CIRCUIT command. All DECnet nodes on the Ethernet should 
respond to the loop request. The loop test is successful if at least 
one other system responds, indicating that the executor node's NIA20 
is capable of communicating with other Ethernet nodes. 

To be tested, an Ethernet circuit must be in the ON state and the 

SERVICE parameter must be set to ENABLED. Note that, by default, the 

SERVICE parameter is set to DISABLED for Ethernet circuits. For 
example: 

NCP>SET CIRCUIT ETH-0 STATE ON 
NCP>SET CIRCUIT ETH-0 SERVICE ENABLED 

To initiate a looping test to a multicast address, use the LOOP 
CIRCUIT command. For example: 

NCP>LOOP CIRCUIT ETH-0 

Use parameters with the LOOP CIRCUIT command to control the type of 
test information and the number and size of blocks sent during 
testing. Use the COUNT and LENGTH parameters to specify the number of 
blocks and the length of each block (in bytes). 

NCP>LOOP CIRCUIT ETH-0 COUNT 10 LENGTH 300 

Use the WITH parameter to specify the type of binary information sent 
during loopback testing. You can specify three types of binary 
information: 

ONES All binary ones 

ZEROES All binary zeros 

MIXED A random combination of ones and zeros 

For example, the following command sends 10 blocks 300 bytes long, 
each containing all binary ones, over the circuit: 

NCP>LOOP CIRCUIT ETH-0 COUNT 10 LENGTH 300 WITH ONES 



3.6.2.2 Looping to a Remote Node - Use the LOOP CIRCUIT NODE command 

to test a logical link path over a circuit between the local node and 

a remote node. You can specify the node's physical address or node 
name in the LOOP CIRCUIT command. For example: 

NCP>LOOP CIRCUIT ETH-0 PHYSICAL ADDRESS AA-00-BB-11-CC-22 

or 

NCP>LOOP CIRCUIT ETH-0 NODE TOSCA 

You can also specify the COUNT, LENGTH, and WITH parameters. 
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3.6.3 Remote Loopback Tests Using a Loop Node Name 

In DECnet-10, these tests can be used for DTE and Ethernet circuits. 

Use the LOOP NODE command with a loop node name to test both local and 
remote Routing layer software operation. For example: 

NCP>SET NODE TESTER CIRCUIT ETH-0 
NCP>LOOP NODE TESTER 

Note that you cannot assign two loop node names to the same circuit. 
For example, once you establish TESTER as the loop node name for 
circuit ETH-0, you must issue a CLEAR NODE TESTER CIRCUIT command 
before assigning another loop node name to ETH-0. 

When a logical link connection request is made to the loop node name, 
all subsequent logical link traffic is directed over the associated 
circuit. The destination of the traffic is whatever node address is 
associated with the loop node name. The loop node name is necessary 
because, under normal operation, DECnet Routing software selects which 
path to use when routing information. The loop node name overrides 
the routing function so that information can be routed over a specific 
circuit. To remove the association of the loop node name with a 
circuit, use the CLEAR NODE CIRCUIT or CLEAR NODE ALL command, as in 
the following command: 

NCP>CLEAR NODE TESTER CIRCUIT 

A loop node name specified with the SET NODE CIRCUIT command may be 

used for any network traffic (for example, COPY requests or 

application program traffic) . The loopback node name appears as a 
valid node name in the network for all purposes. 



3.6.4 Manual Procedure for Observing CHKll Output 

You can use the following commands to observe CHKll output: 

.R DTELDR 
*/TALK:nn 

where: 

nn is the two digits associated with DTE identification. 
For example, for DTE-0-1, type "01" for "nn". 

You must run CHKll before NML does a dump or load of the MCB, with 
this procedure the CHKll output is not output to SYS: ERROR. SYS. 

You can also use SPEAR to examine SYS:ERROR.SYS after CHKll has been 
recorded by Network Management. 



3.7 NODE IDENTIFICATION 

When configuring the network, you must identify, in the executor 
configuration database, the local node and all network nodes with 
which the local node expects to communicate. Identifying all nodes by 
name as well as address permits you to reach any node by its name. 
This section describes node identification and NCP parameters relevant 
to identifying nodes. 
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Either the node address or the node name can serve as a node 
identifier (node-id) in NCP commands; in all other network 
applications only the node name may be used. The node address is a 
decimal number assigned to the node in the configuration database. 
The address must be unique within the network. The node address may 
include, as a prefix, the area number, an integer indicating the area 
in which the node is grouped. In the node address, the area number 
and node number are separated by a period, in the following format: 

area-number .node-number 

For example, if node 3 is in area 7, its node address is 7.3. The 
area number must be unique within the network and the node number must 
be unique within the area. If you do not specify an area number, the 
area number of the executor node is used. The default area number for 
the executor is the number of your local area. In multiple-area 
networks, it is recommended that you always specify the area number. 

A node name is a unique alphanumeric string that contains up to six 
characters including at least one alphabetic character. It must start 
with an alphabetic character. 

Before a remote node can be accessed by name, you must specify the 
node name to be associated with a node address. Use the SET NODE 
command to specify node names and node addresses. The command below 
associates the node name TOSCA with the node whose address is 1.5, 

NCP>SET NODE 1.5 NAME TOSCA 

Once you set the executor node's address, you cannot change it unless 
you restart the system. For DECnet-10, the executor's node address is 
specified during the system build (MONGEN) , and cannot be changed 
without rebuilding and reloading the system. 



3.7.1 Maximum Address Parameters 

The MAXIMUM ADDRESS parameter sets the highest node address, and 
consequently, the greatest number of nodes that can be recognized by 
the local node. Both the DN20 and the KL10 have maximum address 
parameters. The maximum address for the DN20 is set with the NETGEN 
command DEFINE EXECUTOR MAXIMUM ADDRESS, and the maximum address for 
the KL10 is set with the MONGEN dialog (see the TOPS-10 DECnet and PS I 
Installation Guide ) . The range for the DN20 is 2-255, and the default 
is 255. The range for the KL10 is 1-1023, and the default is 1023. 

It is recommended that you set the DN20 and KL10 maximum addresses to 
the same number, if possible. This will insure that the same nodes 
can be recognized by the DN20 and the KL10. If for example, the KL10 
maximum address is set to 1023 and the NIA20 goes down, communication 
with nodes above address 255 can not be resumed through the DN20. It 
is also recommended that you set these parameters to the smallest 
number possible to minimize overhead and memory usage. 



3.7.2 Local Node Identification Parameter 

In addition to defining a node name and address for the local node, 
you can also specify a descriptive quoted string of alphanumeric 
characters. Use the IDENTIFICATION parameter with the SET EXECUTOR 
command to specify this optional information: 

NCP>SET EXECUTOR IDENTIFICATION ••TOPS-10 END NODE" 
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NCP displays this identification in the SHOW EXECUTOR command display; 
NCP>SHOW EXECUTOR 

Identification = TOPS-10 END NODE 



NCP> 



3.7.3 Using and Removing Node Names and Addresses 

Once you have specified a node name and address, you can use them 
interchangeably whenever you need to specify a node-id in an NCP 
command. The local DECnet-10 software translates the node names into 
node addresses. For example, where node TOSCA is set to address 7.5, 
these NCP commands perform identical functions: 

NCP>SHOW NODE 7.5 CHARACTERISTICS 
NCP>SHOW NODE TOSCA CHARACTERISTICS 

To remove a remote node address from the volatile database, you must 
remove all parameters for the node as in the command: 

NCP>CLEAR NODE TOSCA ALL 

On a DECnet-10 node, the CLEAR NODE ALL command removes all parameters 
except for the node name. To remove a remote node name from the 
volatile database, use the CLEAR NODE command. The following command 
removes the association between TOSCA and node 7.5: 

NCP>CLEAR NODE 7.5 NAME 

Once all parameters for a component are removed from the volatile 
database, the component is no longer recognized by the executor. 



3.8 ETHERNET ADDRESSES OF NODES 

Nodes on Ethernet lines are identified by unique Ethernet addresses, 
A message can be sent to one, several, or all nodes on an Ethernet 
line simultaneously, depending on the Ethernet address used. The 
Ethernet address of a TOPS-10 node must be changed to a format that is 
recognized by DECnet, 



3.8.1 Format of Ethernet Addresses 

An Ethernet address is 48 bits in length. Ethernet addresses are 
represented by six pairs of hexadecimal digits (6 bytes) , separated by 
hyphens (for example, AA-01-23-45-67-FF) . The bytes are displayed 
from left to right in the order in which they are transmitted; bits 
within each byte are transmitted from right to left. In the example 
AA-01-23-45-67-FF, byte AA is transmitted first; byte FF is 
transmitted last. 
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Xerox Corporation assigns a block of addresses to a producer of 
Ethernet interfaces upon application. Thus, every manufacturer has a 
unique set of addresses to use. Normally, one address out of the 
assigned block of physical addresses is permanently associated with 
each interface (usually in read-only memory). This address is known 
as the Ethernet hardware address of the interface. 

DECnet-10' s interface to the Ethernet is the NIA20. To be compatible 
with DECnet, the NIA20 must be set to a different address known as the 
Ethernet physical address. DECnet-10 sets the system's Ethernet 
address to the correct value for the operation of DECnet-10. 

The Ethernet physical address is constructed by appending the 16-bit 
executor node address to a constant 32-bit number ( AA-00-04-00) within 
the block of Ethernet addresses assigned to DIGITAL. 



+ + 



32 bits 



16 bits 



Construct within I DECnet node 
Ethernet block assigned | address 

to DIGITAL I 

+ -I- 

An example is a Phase IV routing node with DECnet address 1.182 
(decimal) , which would be set to an Ethernet physical address of 
AA-00-04-00-B6-04. 

Once the Ethernet physical address has been set to its new value, it 
is reset to its original hardware address value only when a reset is 
issued to the NIA20 (for example, when the machine power is shut off). 

The Ethernet physical address of a node includes the number of the 
area in which the node resides. The area number is represented by the 
most significant 6 bits of the 16-bit DECnet node address, while the 
number of the node within the area is indicated by the least 
significant 10 bits of the node address. 

If an existing network is not divided into areas, the default area 
number 1 is stored in the DECnet node address of each node. 
Conversion of an existing network to a multiple-area network may 
require modification of the area number in the executor node address. 



3.8,2 Ethernet Physical and Multicast Addresses 

An Ethernet address can be a physical address of a single node or a 
multicast address, depending on the value of the low-order bit of the 
first byte of the address (this bit is transmitted first) . The two 
types of node address are physical and multicast addresses. 

The Ethernet physical address is the unique address of a single node 
on any Ethernet (as described previously). The least significant bit 
of the first byte of an Ethernet physical address is 0. (For example, 
in physical address AA-00-04-00-FC-00, byte AA in binary is 1010 1010 
and the value of the low-order bit is 0.) 
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The Ethernet multicast address is a raultidestination address of one or 
more nodes on a given Ethernet. The least significant bit of the 
first byte of a multicast address is 1. (For example, in the 
multicast address AB-22-22-22-22-22, byte AB in binary is 1010 1011 
and the value of the low-order bit is 1.) A multicast address can be 
either of the following: 

o Multicast group address. An address assigned to any number 
of nodes; this address can be used to send a message to all 
nodes in the group in a single transmission. The number of 
different groups that can be formed equals the maximum number 
of multicast group addresses that can be assigned, 

o Broadcast address. A single multicast address (specifically, 
FF-FF-FF-FF-FF-FF) that can be used to transmit a message to 
all nodes on a given Ethernet. (Note that the broadcast 
address should be used only for messages to be acted upon by 
all nodes on the Ethernet, since all nodes must process 
them.) 



3.8.3 Values of DIGITAL Ethernet Physical and Multicast Addresses 

DIGITAL physical addresses are in the range AA-00-00-00-00-00 through 
7>A-00-04-FF-FF-FF. Multicast addresses assigned for use in 
cross-company communications are: 



Value 


Meaning 


CF-00-00-00-00-00 


Broadcast 

Loopback assistance 



DIGITAL multicast addresses assigned to be received by other DIGITAL 
nodes on the same Ethernet are: 



value 


Meaning 


AB-00-00-01-00-00 

AB-00-00-02-00-00 

AB-00-00-03-00-00 

AB-0 0-0 0-0 4-00-00 

AA-00-00-05-00-00 

through 
AA-00-03-FF-FF-FF 

AB-00-04 -00-0 0-00 

through 
AB-00-04-FF-FF-FF 


Dump/load assistance 
Remote console 
All Phase IV routers 
All Phase IV end nodes 
Reserved for future use 

For use by DIGITAL customers for 
their own applications 



DECnet always sets up the Ethernet controller at each node to receive 
messages sent to any address in the above list of DIGITAL multicast 
addresses. Only appropriate address are set up. 
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3.9 DATA LINK CONTROL 

Several local node parameters regulate various aspects of physical 
line operation. These are the size of NSP receive buffers and 
transmit buffers (segment buffers) , the number of buffers used to 
transmit on all circuits, and the number of circuits that the local 
node can use as DECnet-10 communication lines. Four parameters are 
provided for this purpose: RECEIVE BUFFER SIZE, SEGMENT BUFFER SIZE, 
MAXIMUM BUFFERS, and MAXIMUM CIRCUITS. You should be careful to set 
the values for these parameters to a reasonable level, or system 
performance might suffer. The parameters all have reasonable default 
values. 

The RECEIVE BUFFER SIZE and MAXIMUM BUFFERS parameters can only be set 
at system build time. The MAXIMUM CIRCUITS parameter can be set using 
the NCP command SET MAXIMUM CIRCUITS. The SEGMENT BUFFER SIZE cannot 
be changed. 



3.9.1 Setting the Buffer Size 

The buffer size must be the same throughout the network for 
communication between all DIGITAL operating systems running DECnet. 
To accept incoming messages of all possible sizes, an executor's 
BUFFER SIZE should be as large as the BUFFER SIZE of the remote 
(sending) node. The DECnet-10 default value for BUFFER SIZE, 576 
bytes, is the BUFFER SIZE most commonly used by DIGITAL systems that 
support DECnet Phase IV. To accommodate Routing messages, the BUFFER 
SIZE must be at least 290 bytes. 

This value is set by the monitor symbol %DLBSZ, which is set with the 
MONGEN dialog when the system is built. 

NOTE 

It is strongly recommended that you use the same 
buffer size for all nodes in your network. Otherwise, 
nodes with smaller buffer sizes will drop packets when 
you attempt to route through them. 

The maximum buffer size for the DN20 is 576 bytes. The maximum buffer 
size for the Ethernet is 1476 bytes. Thus, data can be transmitted 
faster with less processor load on the Ethernet. (The smaller the 
segments, the more messages have to be processed for a given data 
stream.) 

A buffer size that is greater than 576 bytes is used only for Ethernet 
links; the DN20 defaults to 576. Should the Ethernet become 
unavailable when using a maximum buffer size that is greater than 576 
bytes, the interrupted Ethernet links cannot be resumed through the 
DN20. Instead, the user must restart the network operation. 

For example, assume two systems are connected by the Ethernet and by 
DN20S, that both systems are allowing large buffers (greater than 576) 
on the Ethernet. If the Ethernet becomes unavailable, the existing 
logical links are broken and not switched to the DN20. Thus, a file 
transfer being transmitted between the two systems over the Ethernet 
is aborted when the Ethernet becomes unavailable. However, the user 
can start the file transfer again without any intervention required. 
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The buffer size value can be less than 576 bytes; however, the smaller 
value will be the maximum buffer size used on any link, including the 
Ethernet. 

The maximum buffer is actually 17 bytes less than the one set or 
displayed. The 17 bytes are used for DECnet headers. An application 
can use the NSP. UUO to find the maximum buffer size, so that it can 
use messages that are a multiple of the buffer size for maximum 
efficiency. 

The maximum size of the transmit buffer is specified in the SEGMENT 
BUFFER SIZE parameter. This parameter cannot be changed in DECnet-10. 
The segment buffer size is in the range of 256 to 576 bytes and is 
automatically set to the same value as the buffer size. However, if 
the buffer size is set to a value greater that 576, the segment buffer 
will remain at 576 bytes. 

You should consider the following when selecting the buffer size 
value, 

o Faster lines perform better with large buffers and large user 
messages that reduce the processor load. (The smaller the 
segments, the more messages are processed.) 

o Lines that are error prone (for example, telephone lines) 
should use small buffers (256 bytes) to reduce both the 
probability and the cost of retransmissions. 



3.9.1.1 Maximum Number of Buffers - The value that you assign 
determines the size of internal data structures for DECnet-10 
software. For most operations, DECnet-10 will allocate only as many 
buffers as it needs (even if you specify a greater number than the 
amount needed) , and will not allocate more than the number of buffers 
that you specify. 



3.9.1.2 Maximum Number of Circuits - To specify the maximum number of 
routing circuits that can be used, use the MAXIMUM CIRCUITS parameter. 
This value determines the size of internal data structures for 
DECnet-10 software. For example, the following command establishes an 
upper limit of 3 circuits that the local node can use: 

NCP>SET EXECUTOR MAXIMUM CIRCUITS 3 

The default value is 16, 



3.10 REMOTE FILE ACCESS - FAL 

The TOPS-10 File Access Listener (FAL) provides network-level remote 
file access capabilities as specified in the Data Access Protocol 
(DAP) . FAL enables remote network processes to gain access to the 
local TOPS-10 file system. FAL runs as a GALAXY-con trolled request 
queue called a FAL-stream. You can have multiple FAL streams 
operating at the same time. 
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3.10.1 FAL Mode Operation 

FAL is controlled by the OPR program. All commands are issued in OPR 
and all status information is output by OPR. The OPR program has the 
following commands for FAL: 

o SET Command 

The SET command specifies which network each individual FAL stream 
will talk to. The SET command format is: 

SET FAL-STREAM stream-list NETWORK network 

where: 

stream-list is a stream number or range of stream numbers to be 
affected, 

network is either ANF or DECnet. Specify DECnet to have the 
FAL stream perform Input/Output (I/O) with a DECnet 
network, 

o START Command 

The START command is used to start up FAL's I/O streams to allow 
remote file access. The START command format is: 

START FAL-STREAM stream-list 

where: 

stream-list is the list of FAL I/O streams to be started. 

The START command directs FAL to Initiate an inactive I/O stream so 
that remote file accessors can gain entry into the local file system. 
The START command does not actually start any I/O, it merely enables 
the FAL process to receive and process remote file access requests. 

o DEFINE Command 

The DEFINE command sets parameters that apply to all FAL streams. The 
DEFINE command format is: 

DEFINE FILE-ACCESS REJECTION-LIST NODE: : [P,PN] , . . , 

All connections for NODE::[P,PN] will be rejected. PPNs can be 
wildcarded, for example: 

OPR>DEFINE FILE-ACCESS REJECTION-LIST [1,2], MRVAX:i[*,*] 

DEFINE FILE-ACCESS DEFAULT-PPN [P,PN] sets the account under which all 
FAL accesses, without access control information, will be executed. 
The default is [377777,377777]. For example: 

OPR>DEFINE FILE-ACCESS DEFAULT-PPN [2,5] 
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o ABORT Command 

The ABORT command terminates an active I/O stream request. The ABORT 
command format is: 

ABORT FAL-STREAM stream-list 

where: 

stream-list is the I/O streams to be aborted. 

The ABORT command immediately terminates the I/O streams specified. 
No warning is given to the remote 'active' accessing process. The 
effect on the I/O stream is the same as if the job had executed a 
'RESET'; any file OPEN for input is closed, and any file OPEN for 
output is aborted. 

o SHOW Command 

The SHOW command displays the status of the current FAL I/O streams. 
The SHOW command format is: 

SHOW STATUS FAL-STREAM 

or 

SHOW PARAMETERS PAL-STREAM 

Examples: 

OPR>SHOW STATUS FAL-STREAM 
OPR> 

Fal-Stream Status: 

Strra Status Node Connect Time Bytes 

Idle 

1 Active KL5872 0:00: :50 631 

Reading file DSKA:FAL.MEM for user [10,5535] 

2 Connect MRVAX 

3 Idle 

4 Idle 

5 Active BOSTON 0:10:41 65102 

Writing file LPT700 :QPRV2.MEM for user [60,5635] 

6 Idle 

7 Idle 

8 Idle 

9 Idle 
OPR> 

OPR>SHOW PARAMETERS FAL-STREAM 

OPR> 

11:36:06 — System Device Parameters — 

Fal-Stream Parameters: 



rm 


Network 





DECnet 


1 


DECnet 


2 


DECnet 


3 


DECnet 


4 


ANF-10 


5 


ANF-10 



OPR> 
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o SHUTDOWN Command 

The SHUTDOWN command terminates PAL-based I/O operations in an orderly 
manner for a specified stream. The SHUTDOWN command format is: 

SHUTDOWN FAL-STREAM stream-list 

where: 

stream-list is the I/O streams to be shutdown. 

The SHUTDOWN commmand immediately aborts and terminates all dormant 

I/O streams selected. All currently active I/O streams selected are 

marked for termination when the remote active process releases control 
of the DAP link. 

o STOP Command 

The STOP command temporarily freezes FAL I/O streams. The STOP 
command format is: 

STOP FAL-STREAM stream-list 

where: 

stream-list is the list of I/O streams to be frozen. 
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CHAPTER 4 
THE NETWORK CONTROL PROGRAM 



4.1 OPERATOR INTERFACE 

The Network Control Program (NCP) commands provide the only user 
interface to operational controls and measurements of DECnet-10 
Version 4.0. This manual uses the term NCP to refer to the 
application-specific subset of commands that are part of NML. NML 
refers to the entire program (commands, local processing routines, and 
dispatching of IPCF and NICE messages) . 

NCP commands are executed on the TOPS-10 operating system as one set 
of application commands available through the operator interface 
program OPR. In this case, the application is DECnet-10 running under 
TOPS-10 V7.03. 

The DECnet-10 DN20 communications front end on 
DECsystem-1090/1091/1095 systems has no direct command interface. NCP 
commands to control the network or obtain network information are 
executed through the NCP on the DN20's host or the NCP on another 
network node. 



4.2 PROCESSING OVERVIEW 

During GALAXY generation, with the GALGEN program, NCP tables are 
supplied to OPR. These tables provide the information needed by OPR 
to parse the NCP commands. A command that is syntactically correct is 
accepted by OPR, formatted as an IPCF packet, and sent to ORION. 
ORION dispatches the packet to the Network Control Program. The 
program acknowledges all commands received by returning an IPCF packet 
for output to the user's terminal. Therefore, NCP commands cannot be 
executed if ORION is not running. 

How and where the NCP commands are processed and executed is 
determined by the NCP's analysis of the command. OPR/NCP generic 
commands, commands that can be processed locally without access to 
other architectural layers, commands to be processed locally that do 
require interlayer communication, and commands to be processed by 
remote nodes, all follow different paths. You can save time in 
recovering from abnormal situations if you know the path taken by 
commands. If, for example, ORION stops running when you are in the 
process of entering a command to be processed locally by the NCP/NML 
process, there is no point in looking further for the cause of the 
problem. The NCP request cannot be forwarded to NCP/NML until you, or 
another operator with that responsibility, restores ORION. Chapters 5 
and 6 describe the processing path for the generic commands and the 
locally processed commands requiring a minimum of processing. In 
general, these commands are simple in format and easy to understand. 
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Commands requiring communication with other architectural layers in 
the local system and commands to remote nodes require additional 
parameters because of the more complex nature of interlayer and 
node-to-node communication. These commands are processed by routines 
in the NML of the local or remote node. Commands processed by NML are 
described in Chapter 7. 

Both IPCF and NICE messages (used to communicate with NML) are 
internal and transparent to you as an operator entering NCP commands. 
As an operator, your responsibility is to type the NCP commands 
accurately and completely. Sections 4.4 and 4.5 will help you in 
typing and checking the NCP commands. 

Refer to Figure 1-3 to review the processing flow described above and 
preview the flow to follow. 



4.3 NCP FUNCTIONS 

NCP commands perform two major functions: 

o Controlling network activity 

o Monitoring network activity 

Control functions you can perform with NCP Include: 

o Downline loading of a DN20 or Ethernet Communication Server 
(DECSA) 

o Setting and changing line, node, circuit, and logging 
parameters 

o Changing the network configuration 

o Modifying message-traffic patterns 

o Initiating and terminating network functions 

Monitoring functions you can perform with NCP include: 

o Upline dumping of a DN20 

o Displaying information about network entities (their 
characteristics and/or states) and counters 

o Displaying the status of operations on the network, including 
operations in progress and operations that have failed 

o Measuring network performance by displaying the contents of 
counters and the output of the Event Logger through the SPEAR 
program. 

o Performing loopback tests 

The planning function is served by collecting information from the 
day-to-day control and monitoring functions. This information, 
however, must be organized and saved in usable form. 
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4.4 NCP FEATURES 

The NCP command language has many features that make it easy to use, 

4.4.1 Typing Commands at the Terminal 
There are three ways to type commands: 

o Full input mode 
o Recognition mode 
o Abbreviated mode 
Each of the following commands is acceptable: 
Example using full input: 

NCP>SHOW KNOWN CIRCUITS SUMMARY 
Example using recognition: 

NCP>SH<ESC>OW K<ESC>NOWN C<ESC>IRCUITS SU<ESC>MMARY 
Example using abbreviation: 
NCP>sh k c su 

4.4.2 Editing Commands 

You can use the following character commands to edit your input to 
NCP. Because of the more complex nature of the NCP commands, you may 
wish to add to your current use of these commands. 



o DELETE 



Moving backwards from the last character typed, deletes 
one character each time you press the DELETE key. 



o CTRL/U 



Deletes all characters typed since the beginning of the 
line, 

O CTRL/W 

Deletes back to the last punctuation character (including 
space) . 

o CTRL/H 

t 

Used after receiving a format-error message, retypes the 
command up to the point of error. 



o CTRL/R 



Used to display the current command line, omitting 
characters you have deleted. 
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4.4.3 Using Comments 

You can include comments on the command line or on a separate line by 
prefixing the comment with a semicolon or exclamation point. The 
semicolon causes the remainder of the line to be considered as a 
comment; the exclamation point causes only the text up to the next 
exclamation point or the end of the line to be considered as a 
comment. 



4.4.4 Multiple Line Commands 

A long command can be continued to the next line by simply typing the 
command past the end of the line onto the next line. The system 
allows fields of a command to be split between two lines. If you want 
to avoid splitting a command field, type a hyphen as the last 
character in the line. For example: 

NCP>SET EXECUTOR HARDWARE ADDRESS 11 INCOMING TIMER 30 - 
STATE ON 



4.4.5 Getting Help from NCP 

Helpful text is output to your terminal if you type a question mark at 
the beginning of any field. 

Note, in the example that follows, how using the question mark guides 
you through the correct format of a command. Assume you wish to check 
current network activity. You know that the command keyword for 
display is SHOW, but you are uncertain about the rest of the command. 
You proceed as shown below, checking for both possible choices and 
command completion. Command completion is implied when the response 
is "confirm with carriage return". 

NCP>SH<ESC>OW ? one of the following: 

ACTIVE ADJACENT AREA CIRCUIT EXECUTOR KNOWN 

LINE LOGGING LOOP MODULE NODE QUEUE 

SIGNIFICANT 

NCP>SHOW K<ESC>NOWN ? one of the following: 

AREAS CIRCUITS LINES LOGGING MODULES NODES 

NCP>SHOW KNOWN N<ESC>ODES ? one of the following: 
CHARACTERISTICS COUNTERS STATUS SUMMARY 

NCP>SHOW KNOWN NODES ST<ESC>ATUS ? confirm with carriage return 

NCP>shOW kNOWN nODES stATUS 

NCP> 

14:52:50 NCP 

Request # 116; Show Known Node Status Completed 

Node » State Active Delay Type Cost Hops Circuit 

Links 
1(TOPS20) Unreachable 5 
7. 2 (RALPH) Unreachable 

7.3(PIONER) Reachable Routing IV 14 5 DTE-0-1 

7.4(TOPS10) Reachable 1 Routing IV 19 8 ETH-0 



(Output continues.) 
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4.5 NCP COMMAND OPERATION 

The following sections describe how to use NCP commands, 



4.5.1 Accessing NCP Commands 

The Operator Command Language program, OPR, provides the operator with 
one command language to communicate with TOPS-10 application programs, 
including the Network Control Program, To invoke NCP, run OPR and 
then give the command ENTER NCP: 

.R OPR 

OPR> ENTER NCP 

NCP> 

Alternatively, you can execute a single NCP command from OPR command 
level by typing NCP followed by the NCP command: 

OPR>NCP SHOW KNOWN NODES 

To return to the TOPS-10 monitor from NCP, type EXIT. The system 
prints the TOPS-10 prompt, ".". 



4.5.2 Access Control 

If a node- id in a command represents a node to be connected to, you 
may need to enter access control information. Access control 
information can consist of one or any combination of the keywords 
USER, PASSWORD, and ACCOUNT, each keyword followed by a valid value. 
Access control parameters follow the node- id in the command string. 

With the USER parameter, specify a project-programmer number or 
user-name (up to 39 characters) (for the MCB, the information 
specified at NETGEN) , The PASSWORD parameter can contain up to 39 
printable characters, and the ACCOUNT parameter can be up to 39 
characters long. Systems other than TOPS-10 may require a format that 
differs from the TOPS-10 format. Each node in the network may limit 
the amount of access control data it will accept, (See Section 6,7 
for more information on the access control parameters,) 



4.5.3 Restricting NCP Commands 

As implemented on TOPS-10, using NCP requires only that you have 
system (.OBSOP) operator privileges. The appropriate values for these 
privileges are entered in ACTDAE.SYS, Your privileges are enabled by 
default when you log in. To set NCP prameters from a remote node, you 
must specify an account that has these privileges or POKE privileges. 
Refer to the TOPS-10 Software Installation Guide if you require 
additional information on accessing and setting values for privileges. 
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4.5.4 Queued Commands 

When NCP cannot immediately process a command, the command is placed 
in the NCP request queue. Once a request is queued, you can resume 
giving NCP commands. The SHOW QUEUE command lists the queued requests 
that are processing or waiting to be processed. 



4.5.5 Command Input 

NCP input takes the form of arguments delimited by one or more blanks 
or tabs. 

If you type a carriage return following the NCP prompt (without typing 
a command) , the NCP prompt is repeated. 

Multiple outstanding commands are permitted. NML processes them in 
the order entered. 



4.5.6 Command Output Response 

The most general output content and format in response to NCP commands 
includes the following: 

time NCP 

Request #nn; Command input status 

Entity type = Entity Identification 
Requested information or "No Information" 

where: 

time is in hours, minutes, seconds (hh:mm:ss) 

Command input is a brief identification of the request you typed 

status is one of: 

Complete - information follows 

Accepted - information follows after a brief 

delay 

Failed - reason for failure follows and, 

optionally, further detail is given 

Entity-type is either AREA, NODE, CIRCUIT, MODULE, LINE, or 
LOGGING (singular or plural form) . If the 
entity-type is NODE, NODE will be preceded by 
EXECUTOR, REMOTE, or LOOP. All commands to change 
either the volatile or permanent data base of a 
remote node should include the required USER and 
PASSWORD parameters. 
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Requested Information differs according to the action requested, the 
entity specified, and the arguments given. 

The output "No Information" means that no parameters have been set. 
No failure of the command is implied. 

Example 1: Request for characteristics of the TOPS-10 node: 

,R OPR<RET> 

OPR>DISABLE OUTPUT-DISPLAY (of) ALL-MESSAGES<RET> 

OPR> 

9:27:41 — OUTPUT DISPLAY for OPR Modified — 
OPR>ENTER NCP<RET> 

NCP>SHOW NODE BOSTON CHARACTERISTICS<RET> 
NCP> 

9 : 28 : 25 NCP 
Request # 255; Show Node Characteristics Completed 
Executor Node = 7,124 (BOSTON) 

Identification = DECnet-10 Version 4,0 

Management Version = 4,0,0 

Loop Count =1 

Loop Length = 127 

Loop With = Mixed 

Identification = RC177B DEC10 Development 

Incoming Timer = 30 

Outgoing Timer = 60 

NSP Version = 4,0,0 

Delay Factor = 48 

Delay Weight = 10 

Inactivity Timer = 120 

Retransmit Factor = 10 

Routing Version = 2,0.0 

Type = Routing IV 

Routing Timer = 120 

Broadcast Routing Timer = 40 

Maximum Address = 255 

Maximum Cost = 100 

Maximum Hops =28 

Maximum Visits =30 

Maximum Broadcast Nonrouters = 64 

Maximum Broadcast Routers = 32 

Maximum Buffers =80 

Buffer Size = 576 

Segment Buffer Size = 576 
NCP> 

Example 2: Request for status of known circuits 
(Executor is SATURN): 

NCP>SHOW KNOWN CIRCUIT STATUS<RET> 
NCP> 

9:29:16 NCP 
Request # 256; Show Known Circuits Status Completed 



Circuit 


State 


Loopback 


Adjacent 


Block 






Name 


Node 


Size 


DTE-0-3 


on 




7,111(CHRY0N) 


576 


DTE-1-3 


On 




7,252(GNOME) 


576 


ETH-0 


On 




7,58 (MARTEN) 


1498 


ETH-0 


On 




7,62 (DEEP) 


1498 



NCP> 
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Example 3: Request for status of known circuits 
(Executor is SATURN) 

NCP>SET EXECUTOR NODE SATURN<RET> 
NCP> 

9:30:07 NCP 

Set Executor Complete 
NCP>SHOW KNOWN CIRCUIT STATUS<RET> 
NCP> 

9:30:51 NCP 

Request # 257 Accepted 
NCP> 

9:30:53 NCP 
Request # 257; Show Known Circuits Status Completed 

Circuit State Loopback Adjacent Block 

Name Node Size 

DTE-0-1 On 7.124 576 
User = Node / 7.129 / SATURN 



KDP-0-0 On 

User = Node / 7.129 / SATURN 

KDP-0-1 On 

Substate = Synchronizing 

user = Node / 7.129 / SATURN 



7.123 



576 
576 



KDP-0-2 On 

Substate = Synchronizing 

User = Node / 7.129 / SATURN 

KDP-0-3 On 

Substate = Synchronizing 

User = Node / 7.129 / SATURN 



576 



576 



NCP>EXIT 

Appendix C lists and explains, in text or by example, all messages 
output to the user's terminal, including the CTY or operator's 
console. 

The general output format given in Appendix C does not apply to NCP 
commands processed by OPR or processed by the local NCP program. All 
commands translated into NICE messages follow the content of the 
format example for DECnet-10 V4.0. The actual order of items and 
their physical placement may differ for other operating systems. 



4,5,7 Specifying the Executor 

DECnet~10 V4.0 is designed to make central, fully distributed, or 
partially distributed control and management possible. An NCP command 
does not have to be executed at the node where it is typed. 
Therefore, the operator must determine and designate the node that is 
to process and execute each command. You can specify the executor by 
implication (allowing the default to be effective), by a SET EXECUTOR 
command, or by using the TELL prefix. For a detailed description of 
how to specify the executor, see the commands in Chapters 6 and 7, 

The operator must be aware of the characteristics (and status) of all 
nodes in the network to effectively determine the ability of a node to 
act as executor for the command node. 
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4.5.8 Specifying Files in NCP Commands 

File specifications used as arguments in NCP commands for execution by 
DECnet-10 nodes follow TOPS-10 file specification conventions. 

The full file specification for DECnet-10 is: 

dev : filename, ext[p,pn] 

The TOPS-10 Operating System Commands Manual describes file 
specifications in detail. 

Example; 

DSK:SECDMC.SYS[1,2] 

Note that the file operations are actually performed by another job, 
so you cannot use job-wide logical names, or depend on search lists or 
paths being set up by your job. You can, however, use ersatz device 
names such as SYS: and SSL:, which are system wide. In the case of a 
load file residing on SYS:, you could use either the specification 
SYS:DTEMPS,SYS or SSL:DTEMPS,SYS [1 ,4] . However, you should avoid 
using DSK:DTEMPS,SYS[1 ,4] , which depends on the search list for your 
job. 
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CHAPTER 5 
NCP COMMANDS PROCESSED BY OPR 



5.1 OPR/NCP COMMANDS 

Some of the OPR commands available in the NCP application subset are 
for general use by operators; that is, for activities other than 
network activities. These commands require no action by NCP. They 
are processed directly by OPR. These commands are: 

ENTER (command subset) application-name 

EXIT (to monitor level) 

PUSH (to monitor level) 

RETURN (to operator command level) 

TAKE (commands from) fileid /DISPLAY 

/NODISPLAY 

WAIT (for) seconds 



5.2 EXAMPLES OF USE OF OPR/NCP COMMANDS 

Because these commands are among those used frequently by operators, 
the description of the input/output examples is specific to network 
functions. Only the OPR/NCP commands appear in red so that you may 
identify them readily. 

Assume that you are the user [20,7100] with operator privileges and 
that you are logged in on a DECsystem-1091 host node. First, you run 
OPR and disable all messages output periodically by the OPR program. 
These commands are never necessary, but they are helpful if you are 
using your terminal under timesharing and wish to avoid interruptions. 
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Next, you enter NCP and check the status of the local node. The 
system reports that "State is On". So far, you have the following 
input/output : 

R OPR^RET> 
6pR>DISABLE OUTPUT-DISPLAY (of) ALL-MESSAGES<RET> 

9:37:39 — Output display for OPR modified — 
OPR> ENTER NCP<RET> 

NCP>SHOW EXECUTOR STATUS<RET> 
NCP> 

5:29:14 NCP 
Request # 27 Show Executor Node Status Completed 
Executor Node = 8.110 (ALPHA) 

State = On 

Physical Address = AA 00 04 00 8E IC 

Active Links =1 
NCP> 

You next type EXIT to return to the TOPS-10 monitor, and then you type 
the NETWORK/DECNET command to check for currently accessible nodes, 
(The NETWORK command without the /DECNET switch displays nodes from 
all networks in the system; it displays ANF-10 nodes as well as 
DECnet-10 nodes.) You type: 

NCP>EXIT<RET> 

. NETWORK/DECNET<RET> 

[DECnet network: local node ALPHA, 134 reachable nodes in area 7] 

ABACUS ABLE ADAM AJAX ALGOL ALIEN ALPHA ALPINE 

ARSON ARUBA ARWEN ASIMOV AURORA BABEL BANZAI BAXTER 

CACHE CAR CASTOR CDR CHAOS CHARLY CHIPS CHUCKL 



WAFER WILBUR WINNIE WIZARD WOMBAT WOOKIE XENON VODA 
ZEKE ZEPHYR ZEUS ZIP ZONKER ZOO 
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You then run OPR again and ENTER NCP, as shown above. The following 
order of commands assumes you wish to check the number of operators 
with jobs on the host node. Satisfied that the system is not 
overloaded, you reenter NCP, Assume that you now wish to check the 
DTE counters. Using the SHOW EXECUTOR command, you find that the host 
node is the executor. You set the EXECUTOR to be the D1026A, You are 
called away from the terminal and repeat the SHOW EXECUTOR command 
when you return. Whenever you interrupt a network session, checking 
the EXECUTOR is desirable. Do not assume that there has been no 
user-activity at your terminal during your absence. Also, the 
EXECUTOR you previously set may have gone off-line. You have added: 

NCP>RETURN<RET> 

OPR>SHOW OPERATORS<RET> 

OPR> 

15:19:07 — Operators — 

Node Type Terminal Job User 

ALPHA system 240 7 OPERATOR [1,2] 

ALPHA system 2 46 OPERATOR [1,2] 

ALPHA system 56 65 ANDERSON [20,7100] 

OPR>ENTER NCP<RET> 

NCP>SHOW EXECUTOR<RET> 

NCP> 

15:19:49 NCP 

Executor Node = 9.110 (ALPHA) 

Identification = DECnet-10 Version 4.0 
State = On 
Active Links = 

NCP>SET EXECUTOR NODE D1026A<RET> 

NCP 

15:41:33 NCP 

Set Executor Complete 
NCP>SHOW EXECUTOR<RET> 
NCP 
15:41:38 NCP 

Request # 39 Accepted 
NCP> 
15:41:39 NCP 

Executor Node = 9.121 (D1026A) 

Identification = DECnet-10 Version 4.0 Release 
State = On 
Active Links = 1 
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In the following example, you have the SHOW COUNTERS command in a file 
named CNTDTE.CMD and use the TAKE command for indirect input. The 
/DISPLAY switch displays the command entered. At this point, you 
continue with whatever network activities you had planned. Finally, 
you use the EXIT command to return to the TOPS-10 monitor, 

NCP>TAKE CNTDTE.CMD /DISPLAY<RET> 

NCP>CLEAR EXECUTOR NODE<RET> 

NCP> 

15:42:10 NCP 

Clear Executor Complete 

NCP>TELL D1026A SHOW CIRCUIT DTE-0-1 COUNTERS<RET> 

15:42:15 NCP 

Request # 43 Accepted 

15:42:16 NCP 

Request # 43; Show Circuit Counters Completed 

Circuit = DTE-0-1 

17443 Seconds Since Last Zeroed 

4059 Terminating Packets Received 

4669 Originating Packets Sent 

63 Terminating Congestion Loss 

39842 Transit Packets Received 

47361 Transit Packets Sent 

3 Transit Congestion Loss 

Circuit Downs 

Initialization Failures 

1532485 Bytes Received 

2522599 Bytes Sent 

43993 Data Blocks Received 

52032 Data Blocks Sent 

NCP>EXIT 

You can now log off or continue with other activities using the 
TOPS-10 monitor. You have in this short terminal session used each of 
the OPR/NCP commands except WAIT. You have also moved efficiently 
among three command sets. 

The format of the WAIT command is: 

WAIT (for) seconds 

where seconds is a number from 1 to 60, 

You use the WAIT command in command files and batch control files; it 
attempts to ensure that the response to one command is output before 
the next command is processed. If you did not insert the WAIT command 
following an NCP command that might take a few seconds to process, it 
is possible for the command sequence to continue or complete before 
the response is output. With experience you will learn to approximate 
the time required for responses in your particular environment. The 
argument cannot exceed 60 seconds, but you can increase the wait time 
by repeating the WAIT command. 
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CHAPTER 6 
NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM 



NCP processes certain commands directly by means of an internal data 
path between NCP and the volatile network data base in the host node 
(the DECsystem-1090/1091/1095 KL10 node or the DECSYSTEM-2020 KS10 
node) , See Figure 1-3 if you wish to review the flow of these 
commands. Commands processed internally by NCP/NML include: 

SET EXECUTOR NODE nodeid (Section 6.1) 

DEFINE EXECUTOR NODE nodeid (Section 6.2) 

CLEAR EXECUTOR NODE (Section 6.3) 

PURGE EXECUTOR NODE (Section 6.4) 

SHOW QUEUE (Section 6.5) 

CANCEL QUEUE REQUEST requestid (Section 6.6) 

[USER ppn] 
TELL nodeid [PASSWORD password] NML-coramand-line (Section 6.7) 
[ACCOUNT account] 

HELP (Section 6.8) 

(TELL and its arguments form a command prefix. A command to a remote 
node follows. The local node processes the prefix, whereas the remote 
node processes the command.) 

Format, function, arguments (keywords and variable data), examples, 
and remarks if called for, follow for each of the NCP commands (and 
prefix) that NCP processes locally. 



6.1 SET EXECUTOR 

SET EXECUTOR NODE nodeid [USER user id] - 
[PASSWORD password] [ACCOUNT account] 

Function: 

The SET EXECUTOR command acts immediately to establish the node 
specified as the processing node for subsequent commands. The 
value of nodeid becomes part of the temporary data base. The 
node specified in the command continues to be sent commands to 
process until you change the executor with another SET EXECUTOR 
command or clear the executor with the CLEAR EXECUTOR command. 
If the system goes down, this value is lost. You cannot execute 
this command remotely. 
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Arguments : 

nodeid This can be the decimal number representing the 
address of the node, or the node name, 

userid These arguments provide access control information and 
password may or may not be required. The system you specify 
account with nodeid sets the required format for these values. 
On TOPS-10 systems, the userid is a ppn or user-name 
up to 39 characters long, the password and the account 
are each up to 39 characters long. For the MCB 
processor, the password is up to eight characters 
long, and the account and userid are each up to 16 
characters long, (See Section 6,7 for more 
information on access control parameters,) 

Examples : 

Example 1: To display characteristics for the DN20 node: 

NCP>SET EXECUTOR NODE D1036A 

NCP> 

14:17:17 NCP 

Set Executor Complete 

Example 2: To change a parameter value, add access information: 

NCP>SET EXECUTOR NODE D1037A USER OPERATOR PASSWORD SECRET 

NCP> 

12:28:32 NCP 

Set Executor Complete 
NCP> 

Remarks : 

Note that commands processed locally receive an immediate 
response of Complete or Failed and are not assigned a request 
number. 

If you specify values for USER and PASSWORD during the generation 
procedures for the DN20 MCB front end, you must specify these 
values in the SET EXECUTOR command if you intend to execute a 
command that alters the DN20's data base. (ACCOUNT is an 
optional parameter, but if present, it must match the value set,) 
If you omit these values when setting the executor, subsequent 
commands that set or change parameter values will fail, 

WARNING 

If you have not set USER and PASSWORD values, any user 
at a remote node can manipulate the MCB operating 
system by setting the executor to your DN20 MCB node. 

You do not need USER and PASSWORD values with the SET EXECUTOR command 
if subsequent commands are to be SHOW commands. 
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6.2 DEFINE EXECUTOR 

DEFINE EXECUTOR NODE nodeid [USER user id] - 
[PASSWORD password] [ACCOUNT account] 

Function: 

The DEFINE EXECUTOR command establishes the specified node as the 
processing node in the permanent data base. This is the default 
value for the executor. When NCP is started, the default 
executor is the node on which the control program is running, 
unless the executor node was previously defined with the DEFINE 
EXECUTOR command. The values in the permanent data base remain 
from one initialization to the next. The executor node in the 
permanent data base can be changed only by the DEFINE EXECUTOR or 
the PURGE EXECUTOR command. 

Arguments: 

The arguments are the same as those defined for the SET EXECUTOR 
command. 

Remarks: 

Not implemented for DECnet-10, 



6.3 CLEAR EXECUTOR 

CLEAR EXECUTOR NODE 

Function: 

The CLEAR EXECUTOR command accomplishes the reverse of the SET 
EXECUTOR command. It removes the value that was previously 
entered in the volatile data base as the executor. After this 
command, the executor defaults to the node on which NCP is 
running unless a DEFINE EXECUTOR command has previously been 
given. For operating systems that support a permanent data base, 
the value in the permanent data base is always the default taken 
when no value is given. For DECnet--10, the executor defaults to 
the TOPS-10 KL10 or KS10 node when this command is executed. The 
CLEAR EXECUTOR NODE command cannot be executed remotely. 

Arguments : 

The keyword NODE acts as the only argument. 
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Example; 



NCP>SET EXECUTOR NODE D1036A USER OPERATOR PASSWORD D1036<RET> 
NCP> 

9:30:41 NCP 

Set Executor Complete 
NCP>SHOW EXECUTOR<RET> 
NCP> 

9:30:53 NCP 

Request # 244 Accepted 
NCP> 

9:30:54 NCP 



Executor Node = 7.129 (D1036A) 

Identification = DECnet-10 4.0 Release 
State = On 
Active Links = 1 

NCP>CLEAR EXECUTOR NODE<RET> 
NCP> 

9:31:27 NCP 

Clear Executor Complete 
NCP>SHOW EXECUTOR<RET> 
NCP> 

9:31:34 NCP 

Executor Node = 7.110 (KL1026) 

Identification = DECnet-10 Version 4.0 
State = On 
Active Links = 2 



NCP> 
Remarks: 



This command is the simplest way to change the executor from the 
DN20 MCB front end to the TOPS-10 KL10 host. 



6.4 PURGE EXECUTOR 

PURGE EXECUTOR NODE 

Function: 

The PURGE EXECUTOR command accomplishes the reverse of the DEFINE 
EXECUTOR command. It removes the value that was previously in 
the permanent data base as the executor. The default executor is 
then the node where NCP is running. 

Remarks: 

Not implemented for DECnet-10. 
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6.5 SHOW QUEUE 

SHOW QUEUE 

Function: 

You use the SHOW QUEUE command to display the NCP-request queue. 
This command causes the display of either a list of NCP-requests 
waiting to be processed, or the message [The queue is empty]. 
Request numbers are assigned in order as commands are received. 
Therefore, request numbers are in ascending order. The numbers 
are consecutive when you are the only operator using NCP. To 
locate the command you entered, refer back to the command. The 
request number is printed immediately before "Accepted" and 
"Completed." 

Arguments: 

None. (NCP-requests is implied.) 

Examples: 

NCP>SHOW QUEUE<RET> 
NCP> 
9:38:22 NCP 

[The queue is empty] 

NCP> 

***** 

NCP>SHOW QUEUE<RET> 
NCP> 
9:41:31 NCP 

Request # 249 Active, Remote, Executor = 7.129 (D2136A) 

Remarks: 

The SHOW QUEUE command is potentially helpful when you receive no 
response from any command within a few seconds. If there is no 
response from SHOW QUEUE, one of two conditions is probable: the 
NML program is busy loading an adjacent node, or the NML program 
is hung. Wait a few minutes, and if there is still no response, 
restart NML. (See Section 3.2.2 for NML restart procedures.) 



6.6 CANCEL QUEUE REQUEST 

CANCEL QUEUE REQUEST request id 

Function: 

Use the CANCEL command to remove a request from the queue before 
processing begins. You can check the status of the request with 
the SHOW QUEUE command. 

Argument: 

requestid requestid is the number assigned to a command 

request by NML; this number is output 
immediately following all commands that will 
be translated into NICE messages (commands in 
Chapter 7.) 

6-5 



NCP COMMANDS PROCESSED BY THE NETWORK CONTROL PROGRAM 



Remarks ; 



You cannot cancel commands processed locally by NCP (commands in 
this chapter) . They are executed immediately and do not appear 
in the queue. Also, you cannot cancel requests that are noted as 
Active. 



6.7 TELL PREFIX 



TELL nodeid 



[USER user id] 
[PASSWORD password] 
[ACCOUNT account] 



command line 



NCP command 
prefix 



Function: 



Access control 
keywords and parameters 



NCP command to 
be executed by 
node named in 
nodeid 



You use the TELL nodeid prefix to designate the node that is to 

execute the command. The prefix is effective only for the single 
command that immediately follows. 

The receiving node can require any combination of the three 
access keywords and parameters, or none of them. The receiving 

node can refuse to execute the command even when access 
parameters meet requirements. (See Remarks.) 



Arguments : 



[USER userid] 
[PASSWORD password] 
[ACCOUNT account] 



You must format access control parameters 
according to the conventions of the 
operating system of the node specified 
in nodeid. 



TOPS-10 format: 

USER [p,pn] or USER user-name 
where: 
P 



pn 

user-name 

PASSWORD password 
where: 

password 



is a field of up to six octal digits 
representing the user's project number. 

is a field of up to six octal digits 
representing the user's programmer number. 

is any combination of ASCII characters not 
exceeding 39. 



is any combination of ASCII characters not 
exceeding 39. 
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ACCOUNT account 

where : 

account is any combination of ASCII characters not 
exceeding 39. 

MCB format: 

PASSWORD is any combination of 6-bit characters not exceeding 
8. 

ACCOUNT is any combination of ASCII characters not exceeding 
16. 

USER is any combination of ASCII characters not exceeding 16. 

TOPS-20 format: 

Each parameter can contain any combination of ASCII characters 
not exceeding 39. 

Other DIGITAL operating systems: 

See the documentation for that system. 

Examples: 

TOPS-10: 

TELL KL1036:: USER [10,5665] PASSWORD DEC10 ACCOUNT NETWRK -<RET> 
ZERO KNOWN LINE COUNTERS 

TOPS-20: 

TELL D2102A:: USER NISI PASSWORD DECNET ACCOUNT 341 -<RET> 
ZERO KNOWN LINE COUNTERS 

Remarks : 

Using the TELL prefix is more efficient than a combination of SET 
EXECUTOR and CLEAR EXECUTOR commands when you need to give only 
one command to a node. Assume you have set the executor to node 
CAR for the purpose of monitoring network traffic there for an 
hour or more. The system manager interrupts you with a request 
to check the status of lines at node BAR. You can use the 
command TELL NODE BAR SHOW KNOWN LINE STATUS. The TELL prefix 
command format overrides the previous setting of the executor to 
node CAR, displays the status of lines at node BAR, and allows 
you to continue with commands to be executed at node CAR. 

Before using this or any other NCP command requiring that access 

control parameters be sent to another node, you should have 

established both the values and the format that is acceptable to 
the remote node. 
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Assuming the access control parameters are correct, the receiving 
node can still reject the connection for a number of reasons. 
For example, all logical links at the receiving node are busy, 
the state of a required object does not allow processing of the 
command, or the receiving node cannot verify parameters given by 
the sender. The receiving node sends the source node a reject 
message with a reason for the rejected connection. Depending on 
the reason given, you must determine the likelihood of obtaining 
a successful connection at a later time. A TELL command could 
also fail if the specified node does not respond in 60 seconds. 



6.8 USING THE HELP COMMAND 

The HELP command provides a convenient display of the function of any 
NCP commands. Typing HELP lists the commands; typing HELP keyword, 
where keyword is an NCP command keyword, lists all possible 
combinations of command keyword and entity keyword. 

Examples: 

NCP>HELP RETURN<RET> 

Use RETURN to return to OPR command level, 

NCP>HELP CLEAR<RET> 

Use CLEAR to clear parameters of an entity from the volatile data 
base. Additional information available 

CLEAR CIRCUIT 
CLEAR EXECUTOR NODE 
CLEAR LINE 
CLEAR LOGGING 
CLEAR MODULE 
CLEAR NODE 

NCP>HELP CLEAR LINE<RET> 

CLEAR LINE is used to clear the volatile line parameters for the 
line(s) identified in the command. 
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CHAPTER 7 
NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER 

7.1 PROCESSING OVERVIEW 

The NCP commands described in this chapter are processed by routines 
in the Network Management Layer (NML) and involve transparent 
conversion of NCP commands to Network Information and Control Exchange 
(NICE) protocol messages. Commands to be executed by the local node 
are processed by the local node' s NML; commands to be executed by a 
remote node are processed by the remote node's NML. 

The NML itself contains most of the logic and data bases needed to 
process the NCP commands. When needed information resides in other 
architectural layers, NML uses its interface to the appropriate layer 
to read or set parameters. Both system managers and operators will 
find that a knowledge of the processing flow of NCP commands will 
increase their efficiency in using and maintaining the network. 

All communication with NML that involves an exchange of data between 
local and remote nodes is by means of the NICE protocol. (This 
includes communication between the 1090/1091/1095 main processor and 
the DN20.) As an operator, you are not required to know the details of 
the NICE protocol. It may be necessary for a programmer to have a 
working knowledge of NICE (refer to the DECnet Digital Network 
Architecture Network Management Functional Specification , Version 
4.0). The Network Control Program understands NICE, and given a valid 
NCP command, will reformat the command-content (now in an IPCF 
message) into a NICE message for the intended NML. There is one NICE 
message for each NCP command. 

When the intended receiver is a remote NML, all DECnet systems use the 
same method of sending the NICE message. The message is sent over a 
logical link provided by End Communication and Session Control. 

When NML receives a NICE message from a remote NML, it always sends an 
acknowledgement to the sender. Following the receipt of a command, 
the NML of the node that acted as executor sends a response to the NML 
of the command node. Here NCP/NML formats this response into an IPCF 
packet; the packet is forwarded to ORION; ORION dispatches the 
response to OPR; the response is displayed on the operator's terminal. 

You have now followed the paths taken by various NCP commands. You 
may wish to refer to Figure 1-3 for a visual review. Note that your 
participation was restricted to entering the NCP command at the 
terminal and receiving an acknowledgement. Later, normally within a 
few seconds, you receive a response that informs you of the 
disposition of the command. When this response indicates no action 
was taken, the system, to the extent possible, gives the reason. 

The examples that follow, beginning in Section 7.4, show both positive 
and negative responses to individual commands. Appendix C contains 
additional examples, including common sequences of commands. 
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7.2 DECnet-10 IMPLEMENTATION AND EXTENSIONS 

DECnet-10 Version 4.0 implements a subset of the NCP commands 
described by DNA for Version 4.0 of Network Management, X. 25-specif ic 
commands are implemented for the PSI software (see Chapter 8) . 
DECnet-10 does not implement commands specific to DMP multipoint. 

In addition, DECnet-10 contains two extensions made to accommodate the 
distinctive hardware characteristics of DECsystem-10, The extensions 
to the DNA specification are: 

o Remote permanent parameters 

The communications front end (DN20) has no modifiable 
permanent memory. Certain MCB (DN20) data base items are set 
during network generation and are stored in the front-end 
system image. The NCP commands PURGE and DEFINE cannot affect 
these values after network generation, 

o Boot DN20 on failure 

This facility detects that the DN20 communications software is 
not communicating with the KL10 processor. The DN20 is then 
automatically reloaded. 



7.3 NML CONCEPTS AND ORGANIZATION OF PARAMETERS 

Some of the NCP commands that NML processes have up to twenty possible 
parameters. Most of these parameters appear in several commands. The 
most commonly repeated keywords that accept other keywords as 
arguments (rather than specific variables like name or line 
identification) appear in this section. You will save yourself time 
if you make the required associations at this time. Until you become 
familiar with the command/entity/keyword/variable combinations, the 
following descriptions of concepts, variables, and groups of 
parameters common to specific entities should help you to choose the 
correct parameter and interpret the output when you use the "?" 
feature. 



7.3.1 Entities 

The major network management keywords are those that immediately 
follow the command action word (such as SET or LOAD) . These keywords 
specify the element on which the command is to act. All other 
keywords act as "labels" for variables to be typed or as requests to 
choose one of a set group of responses. 
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Some entities are either singular or plural. You can include only one 
entity in each command. The following list includes all entities in 
commands processed by the NML for DECnet-10 Version 4.0: 



Singular 



AREA 



CIRCUIT 



LINE 



LOGGING 



MODULE 



NODE 



Plural 

ACTIVE AREAS 
KNOWN AREAS 

ACTIVE CIRCUITS 
KNOWN CIRCUITS 

ACTIVE LINES 
KNOWN LINES 

ACTIVE LOGGING 
KNOWN LOGGING 

ACTIVE MODULES 
KNOWN MODULES 

ACTIVE NODES 
AJACENT NODES 
KNOWN NODES 
LOOP NODES 



7.3.2 Entity Identification 

The plural form of an entity defines and restricts itself. (Active 
lines, for example, are known lines in the ON or SERVICE state.) 
However, you must follow each singular form of an entity by an 
identification in a system-specific format to indicate one specific 
line, circuit, or node. The identification is also referred to as the 
name of the entity. 

NOTE 

Devices that are similar in operations are referred to 
by the same mnemonic. See Appendix F for a list of 
mnemonic device names for devices used by DECnet-10, 



7,3.2.1 Circuit and Line Identification - This section describes the 
identification of circuits and lines in NCP commands. Circuits and 
lines are identified in the same wasy, with the exception of the 
tributary number, which applies only to circuits. 

DTE Identification 

DTE-cpu-unit 

cpu is the number of the CPU on which the DTE resides. 

unit is the number of the DTE unit. 

Example: 

NCP>SET LINE DTE-0-1 STATE OFF 
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Ethernet Identification 

ETH-channel 

channel identifies the specific Ethernet channel, 
DECnet-10 supports only a single channel (ETH-0) . 

Example: 

NCP>SET CIRCUIT ETH-0 STATE ON 

DDCMP Identification 

For DECnet-10, DDCMP circuit and line identification takes one of 
the following formats: 

device-controller 
device-controller- unit 
device-controller .tributary 
device-controller-unit .tributary 

device is the device name, (See Appendix F for a list of 
mnemonic device names.) 

controller is the device's hardware controller. 

unit is the circuit or line number if the device is a 

multiline controller. For multipoint lines, the 
unit number is optional and, if specified, is 
always 0. 

tributary is the tributary node address (for circuits only). 

Example: 

NCP > SET CIRCUIT DMC-0 STATE ON 



7.3.2.2 Node and Area Identification - Either the node address or the 
node name can serve as a node identifier (node-id) , The node address 
may include as a prefix the area number (area-id) . 

node-name 
node-number 
area-number .node-number 

For example, if node 3 is in area 7, its node address is 7.3. If you 
do not specify an area the area number of the executor is used. 

NCP > SHOW NODE AURORA SUMMARY 
NCP>SHOW NODE 6.12 SUMMARY 



7.3.2.3 Logging Identification - The LOGGING entity is followed by an 
identification of the sink-type, rather than an identification of the 
logging entity itself. However, sinktype must always follow LOGGING 
in the command in the same manner that node- id follows NODE. Sinktype 
identifies the place where a copy of the event is recorded. 
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Sinktype must be one of the following: 

o CONSOLE 

o FILE 

o MONITOR (Not implemented for DECnet-10) 
Example: 

NCP>SHOW LOGGING PILE EVENTS 

7.3.2.4 Module Identification - The module entity consists of the 
following modules: 

o CONFIGURATOR (Not implemented for DECnet-10) 

o CONSOLE (Not implemented for DECnet-10) 

o LOADER (Not implemented for DECnet-10) 

o LOOPER (Not implemented for DECnet-10) 

o X25-ACCESS (see Chapter 8) 

o X25-PROTOCOL (see Chapter 8) 

o X25-SERVER (see Chapter 8) 

Example: 

NCP>SHOW MODULE X25-ACCESS 

7.3.3 The Node Entity 

The node is the central entity of the network. All network control 
and monitoring is based on the concept of the node. From the 
standpoint of network management, nodes are either local or remote. 
The local node is the node where you log in. The Network Management 
Layer, the Session Control Layer, the End Communication Layer, and the 
Routing Layer of DNA contain node functions and parameters. 
Associated with nodes are several keywords that require you to choose 
one of several other keywords to qualify or select specific parameters 
for the first keyword. 
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Keywords you can use with the node entity are: 



TYPE 



AREA-ROUTER 



ROUTING-III 
NONROUTING-III 

ROUTING-IV 
NONROUTING-IV 



STATE 



For EXECUTOR node 
ON 
OFF 

SHUT 



RESTRICTED 

For Remote nodes; 
REACHABLE 



UNREACHABLE 



CPU 



PDP-8 
PDP-11 

DECSYSTEM-1020 
VAX- 11 



SOFTWARE TYPE 



SECONDARY-LOADER 

TERTIARY-LOADER 

SYSTEM 



A node that can route packets 
from one node to another 
within its own area and 
between areas. Also known as 
a level 2 router. A DECnet-10 
node cannot be an area router. 

Full Phase III routing node. 

Phase III node without routing 
capability. 

Full Phase IV routing node. 

Phase IV node without routing 
capability. 



Allows logical links. 

Allows no new links, 
terminates existing links, and 
stops routing (not implemented 
for DECnet-10) . 

Allows no new links, does not 
destroy existing links, and 
goes to OFF when all logical 
links are gone (not 
implemented for DECnet-10) . 

Allows no new incoming logical 
links from remote nodes (not 
implemented for DECnet-10) • 



A remote node is REACHABLE if 
the Routing module of the 
executor node believes it has 
a usable path to the remote 
node. 

A remote node is UNREACHABLE 
when the path length from the 
executor to the remote node is 
longer than the maximum hops 
in the network. 

Identifies the adjacent target 
node's CPU type for downline 
loading. 



Identifies initial target node 
program type for downline 
loading the adjacent node. 



All other keyword responses are specific variables (one per keyword) , 
such as number, seconds, fileid and the like. 



7-6 



NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER 



7.3.4 The Circuit Entity 

All circuits have the following choices for the keywords listed: 



SERVICE 



ENABLED 



DISABLED 



STATE 



CLEARED 



OFF 



ON 



SERVICE 



Indicates that the SERVICE 
functions loading, dumping, and 
line loopback testing, are 
performed automatically. 

Indicates that no functions will be 
performed automatically. In the 
case of a DTE, indicates NML will 
not detect when the DN20 goes down, 
and thus will not attempt to reload 
or dump the DN20. 

The link cannot be used, but space 
is reserved for it. Link data 
bases and parameters are not 
present. (Not implemented for 
DECnet-10.) 

The circuit cannot be used by any 
network-related software, it is 
functionally nonexistent. Link 
data bases and parameters are 
present. 

The circuit is available for normal 
use by its owner, with the 
exception of overrides for service. 

Applies only to the volatile data 
base (SET command) . The circuit is 
available for service functions, 
but is not available for use by the 
owner (Routing) . (Not implemented 
for DECnet-10,) 



7.3.5 The Line Entity 

Lines provide physical point-to-point connections. Functions and 
parameters for the line entity come from the Network Management, Data 
Link and Physical Link layers. 

Lines have the following choices for the keywords listed: 



CLOCK 



INTERNAL 



EXTERNAL 



Clock is supplied by a device 
instead of a modem, usually 
used for external cable 
loopback. 

(MCB only) For normal clock 

operating mode (clock signal 

normally supplied by the 
modem) . 
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CONTROLLER LOOPBACK 



NORMAL 



Places the device to loopback 
internally, thus not requiring 
a loopback connector to turn 
data around, 

(MOB only) Can be used for 
modem or cable loopback, 

NOTE 

See Table 7-1 at the 
end of this section 
for relationships 
between the above 
keywords and the 
loopback mode of the 
line. 



DUPLEX 



FULL 



Full duplex mode of 
device. 



the line 



PROTOCOL 



HALF 



DDCMP POINT 



DDCMP CONTROL 



DDCMP TRIBUTARY 



DDCMP DMC 



SERVICE 



LAPB 
ENABLED 

DISABLED 



(MCB only) Half duplex mode of 
the line device. 

(KS10 only) This is the line 
protocol for a point-to-point 
DDCMP connection. 

This is the line protocol for 
the control station (master) 
end of a DDCMP multipoint 
group, (Not implemented for 
DECnet-10,) 

This is the line protocol for 
the tributary (slave) end of a 
DDCMP multipoint group, (Not 
implemented for DECnet-10,) 

(MCB only) This line is in DMC 
emulation mode. 

For X.25 lines. 

Indicates that the SERVICE 
functions loading, dumping, 
and line loopback testing, are 
performed automatically. 

Indicates that no functions 
will be automatically 
performed. In the case of a 
DTE, indicates NML will not 
detect when the DN20 goes 
down, and thus will not 
attempt to reload or dump the 
DN20, 
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STATE 



CLEARED 



OFF 



ON 



SERVICE 



The line cannot be used, but 
space is reserved for it. 
Line data bases and parameters 
are not present. 

The line cannot be used by any 
network-related software. It 
is functionally nonexistent. 
Line data bases and parameters 
are present. 

The line is available for 
normal use by its owner, with 
the exception of overrides for 
service. 

Applies only to the volatile 
data base (SET command) . The 
line is available for service 
functions but is not available 
for use by the owner (the 
executor node implying 
Routing) . 



Table 7-1: Relationship of Clock and Controller Parameters to Mode of 
Line 



Mode of Line 


Clock 


Controller 


Operation 


Normal 


External 


Normal 


Normal operation 


Normal 


Internal 


Normal 


Device supplies clock 
to simulate synchronous 
modem 


Internal 


Internal 


Loopback 


Device loops data 


loopback 






internally 


External cable 


Internal 


Normal 


Cable loopback with 


loopback 






loopback connector 


External modem 


External 


Normal 


Modem loops back data 


loopback 
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7.3.6 The Logging Entity 

The LOGGING entity is the network component that logs significant 
events that occur during operation and/or maintenance of the network. 
An event is defined as a network- or system-specific occurrence for 
which the logging component maintains a record. A partial list of 
significant events includes: 

o Circuit and node counter activity 

o Changes in circuit, line, and node states 

o Service requests (when a circuit or line is put in an 
automatic service state) 

o Passive loopback (when the executor is looping back test 
messages) 

o Routing performance and error counters (circuit, line, node, 
and data packet transmission) 

o Data transmission performance and error counters (when errors 
in data transmission occur) 

o Lost event reporting (when some number of events are not 
logged) 

Events are recorded continuously by the event logger and can provide 
useful information for maintaining the network. in DECnet-10^ you can 
control the logging of events. In particular, you can control the 
type of events to be logged, the source for these events, and the 
location at which these events are logged. You can also control the 
logging component at the local node and its operational state. 

An example of an event is: 

22:46:30 — Message from DECnet event logger — 

DECNET Event type 4.15, Adjacency up 

Event came from node 7.142 (AURORA), occurred 8-JAN-1985 22:46:28 

Circuit DTE-0-1 

Node = 7.143 (FEAURA) 

DECnet-10 automatically logs events to the system error file 
SYS: ERROR. SYS. All users have access to these recorded events by 
running the SPEAR program. 

The logging component is the device or process that records logging 
events. You can select any of the following components. 

CONSOLE A logging console, which is a OPR terminal 

that displays event messages. Set the 
terminal to display event messages with the 
OPR command ENABLE OUTPUT-DISPLAY 
NCP-MESSAGES. 

FILE A logging file, which records events in 

binary format. The logging file is always 
the system error file SYS: ERROR. SYS. 

MONITOR A logging monitor, which is a program or file 

supplied by the user that receives events. 
(Not implemented by DECnet-10.) 
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The sink name identifies the specific console, file, or monitor 
program to which events are to be logged. At the local node, you can 
control the operational state of the logging sink. Use the SET 
LOGGING STATE command to set the sink to one of the following states: 

OFF The sink is not available. Events destined for 

the sink are discarded, 

ON The sink is available for receiving events. 

HOLD The sink is temporarily unavailable and events are 

queued , 



7. 3. 6,1 Event Identification - Events are defined by class and type. 
You can specify the kinds of events to be logged by using the 
following event-list format: 

class ,type 

class Identifies the DNA or system-specific layer to which the 
event pertains, 

type Identifies a particular form of event, unique within an 
event class. 

For example, to specify an event in the Routing layer, you would use 
event class 4. The event types for this class range from to 14, 
Event type indicates aged packet loss, event type 1 indicates 
unreachable node packet loss, and so forth. Refer to the Appendix C 
for a summary of events by class and type. Use the EVENTS parameter 
for the SET LOGGING command to specify those events to be logged. If 
you want to log all event classes and types, use the KNOWN EVENTS 
parameter. When defining the logging component, you must specify 
events to be logged. 

When providing an event list for the EVENTS parameter, you can specify 
only one class for each instance of this parameter. However, several 
formats can define event types for a particular class. You can 
specify a single event type, a range of types, or a combination of the 
two. The following table illustrates these formats. 

Event-list Meaning 

4,4 Identifies event class 4, type 4 

4,5-7 Identifies event class 4, types 5 through 7 

4,5,7-9,11 Identifies event class 4, types 5, 7 through 9, and 11. 
Note that types must be specified in ascending order. 

The commands below ilustrate invalid event lists, 

NCP> SET KNOWN LOGGING EVENTS 4.4,5.1 

NCP>SET KNOWN LOGGING EVENTS 4.7,3-4,1 

The first example specifies more than one event class. The second 
example specifies event types in numerically descending, rather than 
ascending order. 
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You can use the asterisk (*) wildcard character in an event list. 
This character can replace only an event type. The following example 
illustrates the correct use of wildcards: 

NCP>SET KNOWN LOGGING EVENTS 2.* 
This command identifies all event types for class 2 events. 
Two invalid uses of the wildcard character are shown below, 

NCP>SET LOGGING FILE EVENTS *.2-5 

NCP>SET LOGGING FILE EVENTS 4.2-* 

The first command specifies specific event types for all classes. 
Unless you use the KNOWN EVENTS parameter, you can only specify event 
type information for a single class. The second command uses a 
wildcard to specify a partial range of event types. The wildcard 
character denotes the entire range of event types for a given class. 



7,3.6.2 Selecting Events for Logging - The operator or system manager 
can control event logging by using the NCP command SET LOGGING EVENT 
event-list. If you have a fairly small network, you may elect to log 
all events. However in a large network, it is advisable to log only 
significant events. For instance, a level 1 router generates event 
4.15 "adjacency up" each time an Ethernet node comes on-line. With a 
large number of nodes on the Ethernet, numerous "adjacency up" events 
can make it difficult to observe more significant events. 

It is recommended that you enable the Data Link Layer events (class 
5) . These events typically indicate a problem with the Ethernet. 

Once the events to be logged have been selected and set and the 
logging sinks determined, the operator or manager can examine the 
event logger's output periodically. Several avenues that might be 
followed in utilizing the logged data follow. These are only 
suggestions. Familiarity with the network, gained in daily 
operations, will suggest many more ways to capitalize on the event 
logging feature. 

o Network application programs can be tested by setting 
specific counters to zero, running the application program 
and then examining the event output to observe how the 
program affected node and/or network performance. 

o Counters specific to the Routing Layer (circuit counters that 
monitor terminating and transit congestion loss and circuit 
downs, for example) can be used to identify potential 
problems. 

o An examination of the times and dates when potentially useful 
information is lost can be helpful. There are many queues 
and their lengths cannot be infinite. Circumstances will 
occur when an event will no longer fit on the queue. This 
will be recorded as an "event-lost" event, not as an error. 
All processed events are time stamped and identified as to 
source node and entity name, if any is indicated. On the 
basis of these factors certain changes can be made: the 
logging sink can be moved, peak loads can be adjusted by 
schedule changes, or particular events can be dropped from 
logging. Any changes so made should be evaluated by a 
reexamination of the same event counts that suggested the 
adjustment. 
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In order to log events, you must turn logging on. (The DECnet-10 
default has all events enabled for the FILE sink.) To do so, use the 
SET LOGGING command. Use the same command to modify any of the 
logging parameters. To remove any or all parameters from the volatile 
database, use the CLEAR LOGGING command. You must turn the logging 
state to OFF before attempting to use the CLEAR LOGGING command. 



Table 7-2 lists all logging parameters by function, 
according to operational categories. 



and groups them 



Table 7-2: Logging Parameters and Their Function 



Parameter 


Source-Related 


Sink-Related 


Function 


Parameters 


Parameters 


Identifies events 


EVENTS event-list 
KNOWN EVENTS 




Identifies source for 


CIRCUIT circuit-id 




events 


LINE line-id 
MODULE X25-ACCESS 
MODULE X25-PROTOCOL 
MODULE X25-SERVER 
MODULE X29-SERVER 
NODE node- id 




Determines location for 


SINK EXECUTOR 




logging events 


SINK NODE node- id 




Assigns name to 




NAME sink-name 


logging component 






Sets state of 




STATE HOLD 


logging component 




OFF 
ON 



Use the SET LOGGING EVENTS command to specify source-related events, 
and the SET LOGGING STATE command to specify sink-related events. To 
display the status of the logging sinks and the events enabled for 
logging, use the SHOW LOGGING command. The following command displays 
the status of the CONSOLE sink: 

NCP > SHOW LOGGING CONSOLE SUMMARY 



7.3.6.3 DN20 (MCB) Events - Th 
DECnet-10 events. The DN20, si 
events with the KL10. The KL10-g 
are the same events that are acce 
out all other DN20-generated ev 
considerable overhead for the 
connected to a VAX/VMS system, 
messages that are too large for 
DN20 to generate "Partial routing 
When this occurs frequently, i 
logging of class 4 events. 



e DN20 (MCB) and KL10 generate 

nee it has no logging sinks, logs its 

enerated events selected for logging 

pted from the DN20. The KL10 filters 

ents. This filtering can produce 

KL10. For example, if the DN20 is 

the VMS system may send routing 

the DN20 to process. This causes the 

update loss" (event 4.5) events. 

t is recommended that you disable the 
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DN20 events can also be controlled by disabling their generation at 
the DN20. For example, to disable the generation of class 4 events, 
issue the following command to NETGEN, then rebuild the MCBi 

NETGEN> PURGE LOGGING FILE EVENT 4.5 

Since the DN20 does not have a clock, it cannot supply the time of an 
event, DN20 events do however, include the DN20's uptime. Add the 
MCE uptime to the exact time that the DN20 was started to determine 
the time of an event. 



7,3.6.4 Logging Events at Remote Nodes - In addition to logging 
events at the sinks on your node, events can be sent to remote DECnet 
nodes. For instance, you might select a single node to collect all 
the events that occur in the network. In the following example, all 
network management events (class 0) are sent to the logging console on 
node TEAL: 

NCP>SET LOGGING CONSOLE EVENT 0.* SINK NODE TEAL:: 



7.3.7 The Maintenance Module Entity 

The Link Management maintenance modules are responsible for handling 
maintenance functions on circuits and lines. These modules have 
implied responsibility for handling maintenance for all DDCMP and X,25 
data links, and they have specific responsibility for Ethernet 
circuits assigned to them by the network manager. 

The Link Maintenance modules provide entities that can own Ethernet 
circuits for link service functions such as loop testing and downline 
loading. The names of Link Maintenance modules are LOOPER, LOADER, 
CONSOLE, and CONFIGURATOR. 

The LOOPER, LOADER, and CONSOLE modules are the only link maintenance 
modules that can be CIRCUIT owners. They each own one circuit on 
every Ethernet line that is to have their related service functions. 

The CONFIGURATOR module is a user of the services represented by the 
console module. The configurator module can provide information from 
a single console request for system identification or can listen 
through the console and construct a list of systems on an Ethernet 
line. 



7.3.7.1 The CONFIGURATOR Module - The Ethernet CONFIGURATOR module is 
not supported by DECnet-10. The Ethernet CONFIGURATOR module 
maintains a list of all nodes on the Ethernet. Approximately once 
every 10 minutes, each node on an Ethernet circuit that conforms to 
the DNA specifications transmits a system identification message (a 
hello message) to a multicast address that the configurator monitors. 
The configurator module listens to these messages and builds a 
user-accessible database of configuration information for all systems 
on the Ethernet. 

The configurator runs as a separate process, and, once it is started, 
becomes available to all users on the system. 
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The CONFIGURATOR module has the following states for surveillance of 
Ethernet circuits: 

SURVEILLANCE 

ENABLED The list of Ethernet nodes is kept, 

DISABLED The list of Ethernet nodes is not kept. 



7.3.7.2 The CONSOLE Module - The CONSOLE module is not supported by 
DECnet-10, However, a similar function is provided by the RMTCON 
program. 

The CONSOLE module is a logical console terminal (CTY) that is 
connected to a terminal server such as the DECserver 100 Terminal 
Server, This allows control of the terminal server from a remote 
node. When the console receives a message, it becomes reserved for 
the exclusive use of the system that sent the message. After a 
predefined number of seconds, if the console has not received another 
message for the node that reserved it, the console becomes available 
for reservation by another node. The RESERVATION TIMER parameter sets 
the number of seconds that the console will stay reserved without 
hearing from the remote node before being available. 



7.3.7.3 The LOADER and LOOPER Modules - The LOADER and LOOPER Modules 
are not supported by DECnet-10; however, DECnet-10 NCP commands can be 
sent to other operating systems which support these modules. 

A node can request a down-line load or loopback assistance by sending 
a multicast address. Of the nodes that respond to the address, one of 
the responding nodes is selected according to criteria defined by the 
operating system. For example the node might choose the first node to 
respond to the request. The LOOPER and LOADER modules' ASSISTANCE 
parameter indicates whether or not the node will respond to a request 
for a down-line load or loopback assistance. 

The LOADER and LOOPER modules have the following choices for the 
ASSITANCE keyword: 

ASSISTANCE 

ENABLED The node will respond to a dump/load or loopback 
assistance multicast address. 

DISABLED The node will not respond to a dump/load or 
loopback assistance multicast address, 

DECnet-10 does not support the setting of this parameter, LOADER and 
LOOPER ASSISTANCE is always ENABLED on DECnet-10 nodes. 



7.3.8 The Area Entity 

An area is a group of nodes. The system manager can group nodes for 
hierarchical routing purposes. The user can identify areas in two 
major ways: individually and in groups. To identify an area 
individually, use the area number. An area number is a decimal 
integer in the range 1-63, Area 1 is usually used to designate a 
single area network and Area is used when communicating with a 
DECnet Phase III node. 
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Area group identifications are as follows: 

ACTIVE AREAS All areas that the executor perceives routing can 
reach. 

KNOWN AREAS Same as ACTIVE AREAS, 



7.4 GENERIC FORMAT OF NML/NCP COMMANDS 

The generic format of NML/NCP commands is: 

COMMAND ENTITY [KEYWORD] [argument] ... [KEYWORD] [argument] 

Although most commands will have a command entry, an entity entry, and 
at least one keyword/argument combination, the command itself is the 
only element that is always present. The [KEYWORD] [argument] fields 
can also take the form [KEYWORD] [KEYWORD] , as in TYPE ROUTING or 
STATE OFF. In this form, the second KEYWORD acts as an argument for 
the first keyword. Under certain conditions, entity is understood. 
The keyword ALL acts as a pluralistic parameter: used with SET/DEFINE 
or CLEAR/PURGE, ALL indicates all information on the named entity. 

Three pairs of commands - SET and DEFINE, CLEAR and PURGE, and SHOW 
and LIST - affect the same entities and accept the same arguments. 
Thus, except for the command itself, you type the same information in 
the same format. For example: 

NCP>SET LINE KDP-0-0 CLOCK INTERNAL 

NCP>DEFINE LINE KDP-0-0 CLOCK INTERNAL 

The first command changes line parameters in the volatile data base; 
the second changes parameters in the permanent data base (not 
implemented for DECnet-10) . 

SET, CLEAR and SHOW refer to parameters in the volatile data base; 
DEFINE, PURGE, and LIST refer to parameters in the permanent data 
base. These three pairs are considered together in the detailed 
descriptions that follow. All other commands are described in 
separate charts. Remember that neither TOPS-10 nor MCB supports a 
permanent data base. Therefore, for DECnet-10 you can use only SET, 
CLEAR, and SHOW, All commands are given because other operating 
systems may implement a permanent data base. 



7.5 CHANGING NETWORK DATA BASES: SET AND DEFINE COMMANDS 

In DECnet-10 V4.0, you can establish certain initial parameter values 
during network generation. Command files are created that consist of 
NCP SET commands that use these initial values as arguments. These 
commands are executed at system startup and the parameter values they 
set become the initial volatile data base. The operator or system 
manager cannot change or set all parameter values. 
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Values displayed in respons 
values in the original data 
have been chosen to ensure 
for your installation bee 
performance depends. Howev 
reason and some planning 
check performance with the 
have been made. Whether 
performance is best judged 



e to the various SHOW commands are the 

base (unless you have changed them). They 

a viable network. They may not be optimal 

ause of the many factors upon which network 

er, no value should be changed without good 

It is suggested that the system manager 

SPEAR reports both before and after changes 

you have improved or degraded the network 

by actual results. 



To change a value in the volatile data base, you use the appropriate 
NCP SET command. Values established with the SET command are in 
effect for all commands following the SET command unless changed with 
another SET command. Volatile data base values are lost when the node 
is reloaded. 

Access privileges are required to send a SET command to a DECnet-10 
node from a remote node using the TELL prefix. The following access 
information must be added to the command string: 

USER ppn (with or without brackets) or user-name 

PASSWORD password (password used at LOGIN) 

NOTE 

NCP commands that are processed by the local Network 
Management function are described in Chapter 6. 
Commands processed by the OPR program are described in 
Chapter 5. 



7.5.1 SET/DEFINE Entity ALL 

Command Entity Keyword/Argument 

(set ) ( CIRCUIT cktid I ALL 

[DEFINE ( I LINE lineid 

^ ' < LOGGING sink-type 

I MODULE module- type 

I NODE node id 

Function: 

When used with the keyword ALL, the SET command reads all known 
permanent parameters for the named entity into the volatile data 
base. Conversely, the DEFINE command reads all known volatile 
parameters into the permanent data base of the identified entity 
(not implemented by DECnet-10) . 

Arguments: 

You can use the keyword ALL with the commands SET/DEFINE and 
CLEAR/PURGE to indicate all information on the entity identified 
in the command. Refer to the singular form of each entity for a 
complete list of all possible keywords and parameters. 
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Remarks: 



DEFINE and SET commands with the keyword ALL cannot be executed 
by DECnet-10 executor nodes because of the lack of a modifiable 
permanent data base. 

Before attempting to send this command to a non-DECnet-10 node, 
consult the documentation of that node's operating system. This 
command depends upon the specific implementation. 



7.5.2 SET/DEFINE CIRCUIT 

Command Entity 

(set ) CIRCUIT cktid 
[DEFINE ( 



Keywo rd/Arg umen t 

ACTIVE BASE base 

ACTIVE INCREMENT increment 

BABBLE TIME milliseconds 

COST cost 

COUNTER TIMER seconds 

DEAD THRESHOLD count 

DYING BASE base 

DYING INCREMENT increment 

DYING THRESHOLD count 

INACTIVE INCREMENT incrmt 

INACTIVE THRESHOLD count 

LINE lineid 

MAXIMUM BUFFER count 

MAXIMUM TRANSMITS count 

MAXIMUM ROUTERS number 

OWNER owner id 

POLLING STATE polstate 

ROUTER PRIORITY number 

SERVICE srvcntl 

STATE cktstate 

TRANSMIT TIMER millisecs 

TRIBUTARY tribaddr 



Function: 



These commands set volatile and permanent circuit parameters for 
the circuit(s) identified in the command. 

Arguments: 

Arguments for all circuits: 

COUNTER TIMER seconds 

Seconds is a decimal integer in the range 1-65535. Counter 
timer is a Network Management Timer. When the seconds 
indicated have elapsed, the circuit counters are recorded as 
data in a logging event, and then zeroed. The logging 
begins again, and the cycle continues as long as the node 
remains up, or until the counter is cleared. The counter 
timer value must be set for circuit counters to be 
automatically logged. 
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OWNER owner id 

Ownerid consists of an entity type and entity 
identification. The only ownerid currently defined is the 
executor node, (This implies that the circuit is actually 
reserved for Routing, the DECnet routing module.) 
Establishing an ownerid merely reserves the circuit. There 
is no implication as to whether the circuit is open. 
Network Management can always override the owner's exclusive 
rights to the circuit. 

STATE cktstate 

Cktstate can be CLEARED, OFF, ON, or SERVICE. (See Section 
7.3.4 for state definitions.) 

Arguments for DDCMP circuits only: 

LINE lineid 

Lineid is the Data Link layer identification of the line to 
be used by the circuit. (See Section 7.3.2 for format.) 

SERVICE srvcntl 

Srvcntl can be ENABLED or DISABLED, indicating respectively 
that Network Management allows or disallows service 
operations on a circuit. (See Sections 7.3.4 for more 
detail.) 

Arguments for all circuits owned by EXECUTOR: 

COST cost 

Cost is a decimal number in the range 1 to 25. The COST 
parameter is used in the routing algorithm to determine the 
most cost-effective routing path. (See Section 2.3 for more 
information on routing concepts.) 

HELLO TIMER seconds 

Seconds is a decimal number in the range 1-65535. This 
value determines the frequency of Routing Hello messages 
sent to the adjacent node on the circuit. 

LISTEN TIMER seconds 

Seconds is a decimal number in the range 1-65535. This 
value determines the seconds that can elapse before Routing 
receives either a Hello message or a user message from the 
adjacent node on the circuit. 

Arguments for Ethernet circuits: 

MAXIMUM ROUTERS number 

This parameter applies to Ethernet circuits. It specifies 
the maximum number of routers (other than the executor node) 
allowed by the Routing layer for the specified circuit. 
Number is a decimal integer in the range 1-64. The default 
is 16. 
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ROUTER PRIORITY number 

This parameter applies to Ethernet circuits. It specifies 
the priority the specified router (the executor node on the 
circuit) is to have in the selection of a designated router 
for the circuit. Number is a decimal integer in the range 
0-127. The default is 5. 

NOTE 

The DNA Routing Layer Specification contains detailed 
information on the effect of changing parameter values 
of timers used by Routing. (See Appendix E for a 
complete list of DNA Specifications.) 

The following arguments are not implemented for circuits in DECnet-10 
V4.0. Check the documentation for the operating system of the 
executor to direct commands containing these arguments to a remote 
node. 

ACTIVE BASE base 

This parameter applies to DDCMP CONTROL circuits only. The 
value of base represents the base priority to which a 
tributary is reset after each time it has been polled. This 
is the base priority for a tributary in the ACTIVE state. 
Base is a value in the range to 255. If not set, the 
default is 255. 

ACTIVE INCREMENT incrmt 

This parameter applies to DDCMP CONTROL circuits only. The 
value of incrmt represents the increment added to the 
tributary priority each time the scheduling timer expires. 
This increment applies to a tributary in the ACTIVE state. 
Incrmt is a value in the range to 255. If not set, the 
default is 0. 

BABBLE TIMER millisecs 

This parameter applies to DDCMP CONTROL circuits only. The 
value of millisecs represents the number of milliseconds 
that a selected tributary or remote half-duplex station can 
transmit. Millisecs is a value in the range 1 to 65535. If 
not set, the default is 6000 (6 seconds) . 

DEAD THRESHOLD count 

This parameter applies to DDCMP CONTROL circuits only. The 
value of count represents the number of times to poll the 
ACTIVE, INACTIVE, or DYING tributary before changing its 
polling state to DEAD because of receive timeouts. Count is 
a value in the range to 255. If not set, the default is 
8. 

DYING BASE base 

This parameter applies to DDCMP CONTROL circuits only. The 
value of base represents the base priority to which a 
tributary is reset after each time it has been polled. This 
is the base priority for a tributary in the DYING state. 
Base is a value in the range to 255. If not set, the 
default is 0. 
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DYING INCREMENT incrmt 

This parameter applies to DDCMP CONTROL circuits only. The 
value of incrmt represents the increment added to the 
tributary priority each time the scheduling timer expires. 
This increment applies to a tributary in the DYING state, 
Incrmt is a value in the range to 255. If not set, the 
default is 16. 

DYING THRESHOLD count 

This parameter applies to DDCMP CONTROL circuits only. The 
value of count represents the number of times to poll the 
ACTIVE, INACTIVE, or DYING tributary before changing its 
polling state to DYING because of receive timeouts. Count 
is a value in the range to 255. If not set, the default 
is 2. 

INACTIVE BASE base 

This parameter applies to DDCMP CONTROL circuits only. The 
value of base represents the base priority to which a 
tributary is reset after each time it has been polled. This 
is the base priority for a tributary in the INACTIVE state. 
Base is a value in the range to 255. If not set, the 
default is 0. 

INACTIVE INCREMENT incrmt 

This parameter applies to DDCMP CONTROL circuits only. The 
value of incrmt represents the increment added to the 
tributary priority each time the scheduling timer expires. 
This increment applies to a tributary in the INACTIVE state, 
Incrmt is a value in the range to 255. If not set, the 
default is 64. 

INACTIVE THRESHOLD count 

This parameter applies to DDCMP CONTROL circuits only. The 
value of count represents the number of times to poll the 
ACTIVE tributary before changing its polling state to 
inactive because of no data response. Count is a value in 
the range to 255. If not set, the default is 8. 

MAXIMUM BUFFERS count 

This parameter applies to DDCMP CONTROL circuits only. The 
value of count represents the maximum number of buffers the 
tributary can use from a common buffer pool. If not set, 
there is no common buffer pool and buffers are explicitly 
supplied by the higher level. The value of count is either 
a value in the range 1 to 255 or the keyword UNLIMITED. 

MAXIMUM TRANSMITS count 

This parameter applies to DDCMP CONTROL circuits only. The 
value of count represents the maximum number of data 
messages that can be transmitted at one time. Count is a 
value in the range 1 to 255. If not set, the default is 4, 
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POLLING STATE polstate 

This parameter applies to DDCMP CONTROL circuits only. The 
value of polstate represents the state of the tributary 
relative to the multipoint polling algorithm. If not set, 
the default is AUTOMATIC. The possible states are: 

AUTOMATIC - state is allowed to vary according to the 
operation of the polling algorithm. 

ACTIVE/INACTIVE/DYING/DEAD - the tributary is locked in 
the specified state. 

TRANSMIT TIMER millisecs 

This parameter applies to DDCMP CONTROL circuits only. The 
value of millisecs represents the number of milliseconds to 
delay between data message transmits. Millisecs is a value 
in the range to 65535. 

TRIBUTARY tribaddr 

This parameter applies to multipoint DDCMP circuits only. 
Tribaddr represents the Data Link physical tributary address 
of the circuit. Tribaddr is a value in the range to 255. 

Examples: 

1. Set the circuit STATE to ON for the circuit DTE-0-1. 

NCP>SET CIRCUIT DTE-0-1 STATE ON 

2. Set the maximum number of routers permitted on the Ethernet 
circuit ETH-0 to 5. 

NCP>SET CIRCUIT ETH-0 MAXIMUM ROUTERS 5 



Command Entity Keyword/Argument 
(set ) KNOWN CIRCUITS (ALL 



I 



)DEFINE( < COUNTER TIMER seconds) 

^ ' (service srvcntl ) 

Function: 

SET KNOWN CIRCUITS ALL loads all permanent circuit parameter 
values into the volatile data base. (Not supported for 
DECnet-10.) Other SET KNOWN CIRCUIT commands set the specified 
values in the volatile data base of each circuit known to the 
executor. DEFINE KNOWN CIRCUITS ALL has no meaning. Other 
DEFINE KNOWN CIRCUIT commands set the specified parameter values 
in the permanent data bases of all circuits known to the 
executor. 

Arguments : 

Same as for CIRCUIT cktid (singular) . See remarks below. 
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Example ; 



1. Disable service operations (loading and loop testing) for all 
circuits. 



NCP>SET KNOWN CIRCUITS SERVICE DISABLED 



Remarks: 



Although you can use all arguments allowed for SET CIRCUIT 
(described in this section) in the SET KNOWN CIRCUITS commands, 
many of the arguments are inappropriate for plural entities. The 
arguments listed are those most likely to be meaningful. The NML 
program processes all arguments listed under SET CIRCUIT for the 
plural CIRCUITS. However, you should consider the probable 
results carefully before using arguments not listed. 



7.5.3 SET/DEFINE LINE 
Command Entity 



ISET I 
iDEFINEi 



LINE lineid 



Keyword/Argument 

CLOCK clock-mode 
CONTROLLER controller-mode 
COUNTER TIMER seconds 
DEVICE device-id 
DUPLEX duplex-mode 
PROTOCOL protocol-name 
RETRANSMIT TIMER milliseconds 
SERVICE service-control 
SERVICE TIMER milliseconds 
STATE line-state 

For DDCMP lines: 

DEAD TIMER milliseconds 
DELAY TIMER milliseconds 
RECEIVE BUFFERS number 
SCHEDULING TIMER milliseconds 
STREAM TIMER milliseconds 



Function: 

These commands set volatile and permanent line parameters for the 
line(s) identified in the command. SET sets volatile parameters, 
and DEFINE sets permanent parameters for nodes that support a 
permanent data base. 

Arguments: 

COUNTER TIMER seconds 

Seconds is a decimal integer in the range 1-65535. Counter 
timer is a Network Management Timer. When the seconds 
indicated have elapsed, the line counters are recorded as 
data in a logging event, and then zeroed. If no counter 
timer value is set, the line's counters are not 
automatically logged. 
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DEVICE deviceid 

The deviceid specifies the local hardware to be used. It 
consists of a device identification (dev) and a controller 
number (c) if the device supports a single line. For a 
multiple line controller, the deviceid consists of a device 
identification, a controller number, and a unit number (u) . 
For example: 

dev-c-u 

DEVICE DMR-1 
DEVICE KDP-0-2 

PROTOCOL name 

For DECnet-10, this parameter is implemented for the MCB 
node only and for KDP lines only. The protocol name can be 
DDCMP DMC for DECnet-10 lines and LAPS for X.25 lines. 
Other DIGITAL operating systems may permit the values DDCMP 
CONTROL, DDCMP TRIBUTARY, and LAPB. See the appropriate 
documentation. See Section 7.3.5 for definitions if needed, 

RETRANSMIT TIMER milliseconds 

Milliseconds is a decimal integer in the range 1-65535. The 
RETRANSMIT TIMER is a Data Link timer. When the number of 
milliseconds specified have elapsed, a block is 
retransmitted. This timer is used for normal operation of 
the line, 

SERVICE TIMER milliseconds 

Milliseconds is a decimal integer in the range 1-65535. The 
SERVICE TIMER is a Data Link timer that is used during 
service operations. Milliseconds represents the maximum 
amount of time allowed to elapse before a receive request is 
completed. 

Arguments for DDCMP lines. Not implemented for DECnet-10: 

DEAD TIMER milliseconds 

This value represents the number of milliseconds between 

polls for one of the set of dead tributaries. Milliseconds 

is a decimal integer in the range 1-65535, If not set, the 
default is 1000. (10 seconds). 

DELAY TIMER milliseconds 

This value represents the mimimum number of milliseconds to 
delay between polls. The delay timer limits the effect of a 
very fast control station on slow tributaries. Milliseconds 
is a decimal integer in the range 1-65535. If not set, 
there is no delay. 
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RECEIVE BUFFERS number 

Allocates buffers for data reception by the device driver 
for a particular DDCMP line. The number of buffers you set 
depends on throughput requirements and available memory 
pool. A value in the range of 2 to 4 is adequate for line 
speeds of less than 56K bits. For asynchronous lines, a 
value of at least 4 is recommended. Megabit line speeds may 
require eight or more buffers, depending on the observed 
errors, 

SCHEDULING TIMER milliseconds 

This value represents the number of milliseconds between 
recalculation of tributary polling priorities. Milliseconds 
is a decimal integer in the range 50-65535. If not set, the 
default is 200. 

STREAM TIMER milliseconds 

This value represents the number of milliseconds a tributary 
or half duplex remote station is allowed to hold the line. 
Milliseconds is a decimal integer in the range 0-65535. If 
not set, the default is 6000 (6 seconds) . 



CLOCK, CONTROLLER, 
7.3.5. 



DUPLEX, SERVICE, and STATE: See Section 



Examples: 



1. Tell a DECnet-VAX node to set line DMC-0 to the ON state in 
full duplex mode. 

NCP>TELL TOSCA USER ANDERSON PASSWORD NEWBURY SET - 
LINE DMC-0 DUPLEX FULL STATE ON 

2, Tell a DECnet-VAX node to set the line protocol to DDCMP 
POINT for line DMC-0. 

NCP>TELL ALFIE SET LINE DMC-0 PROTOCOL DDCMP POINT 



7.5.4 SET/DEFINE MODULE 
Command Entity 



Keyword/ Argument 



I SET ) 
[DEFINE I 



MODULE CONFIGURATOR [CIRCUIT ckt-id] 

[known circuits] 
(all 

^SURVEILLANCE control 



Function: 

This command is not implemented for DECnet-10. 



Creates or modifies parameters of the 
The configurator module constructs 
specified Ethernet circuits. 



Ethernet configurator module, 
a list of systems active on the 
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Arguments: 

KNOWN CIRCUITS 

Applies only to Ethernet circuits. Specifies that 
configurator information on all known circuits is to be 
stored in the volatile database. 

CIRCUIT circuit-id 

Applies only to Ethernet circuits. Specifies that 
configurator information on the specified circuit is to be 
stored in the volatile database. 

ALL 

Copies all known permanent parameters for the configurator 
into the volatile data base, 

SURVEILLANCE control 

This value indicates whether or not a list of active systems 
is to be kept for the circuit. The control values are the 
following : 

ENABLED The list is kept 
DISABLED The list is not kept 

The default value is DISABLED. 

Examples 

1. Tell node AURORA to keep a list of all active systems on all 
known Ethernet circuits. 

NCP>TELL AURORA SET MODULE CONFIGURATOR KNOWN CIRCUITS - 
SURVEILLANCE ENABLED 

Remarks J 

Once the configurator ceases surveillance of all Ethernet 
circuits it has been monitoring, for example, if you give the 
command SET MODULE CONFIGURATOR SURVEILLANCE DISABLED KNOWN 
CIRCUITS, the list of system information is deleted. 

Command Entity Keyword/Argument 

(set ) MODULE CONSOLE RESERVATION TIMER seconds 
DEFINE I 

This command is not implemented for DECnet-10. 

The SET MODULE CONSOLE RESERVATION TIMER sets the number of seconds 
that the console will stay reserved without hearing from the system 
that reserved it. Seconds is a decimal integer in the range 1-65535. 

Example: 

Set node AURORA'S console reservation timer to 10 seconds: 

NCP>TELL NODE AURORA SET MODULE CONSOLE - 
RESERVATION TIMER 10 
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Command Entity Keyword/Argument 

(set ) (module loader) (assistance control) 
I DEFINE j (MODULE LOOPER J | ALL i 

Function: 

These commands are not implemented for DECnet--10. 

The MODULE LOADER command is for Ethernet up-line dump and 
down-line load. The MODULE LOOPER command is for Ethernet 
loopback testing. 

Arguments : 

assistance state 

This value indicates whether or not the node responds to the 
dump/load assistance multicast address. The state is one of 
the following: 

ENABLED The node will respond 
DISABLED The node will not respond 



The state of a DECnet-10 node is always ENABLED. 



ALL 



Copies configurator module information from the permanent 
data base into the volatile data base at the local node. 

Example: 

Tell node TEAL to enable loader assistance, 

NCP>TELL TEAL SET MODULE LOADER ASSISTANCE ENABLED 

7,5.5 SET/DEFINE NODE 

Command Entity Keyword/Argument 

SET ) NODE nodename CIRCUIT cktid 
DEFINED 

Function: 

This command sets the volatile or permanent address and circuit 
for the specified nodename. The CIRCUIT cktid parameter applies 
to loop nodes and nodes by name only. 

Arguments: 

CIRCUIT cktid 

Cktid is the identification of the circuit to be used for traffic 
to the named node, which is a loop node. For example, the 
command : 

NCP>SET NODE FOOBAR CIRCUIT DTE-0-3 

will create the loop node FOOBAR, so it can be used in LOOP NODE 
commands, 
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Command 


Entity 


Keyword/Argument 


SET 


NODE nodeaddr 


NAME nodename 


DEFINE/ 






Function : 







This command sets the volatile or permanent parameter for the 
nodename to be associated with the specified address. A 
nodename/nodeaddr association is unique. 



Argument: 



Nodename consists of one to six alphanumeric characters with at 
least one alpha character. A node name is associated with one, 
and only one, node address. 

Examples: 

NCP>SHOW EXECUTOR<RET> 
NCP> 

9:35:43 NCP 
Request # 279; Show Executor Node Summary Completed 
Executor Node = 7.110 (KL1026) 
State = On 
Identification = RC177B KL #1026/1042 

NCP>SET NO 7.110 NAME ANYNAM<RET> 
NCP> 

9:43:00 NCP 
Request # 280; Set Node Failed, Component in wrong state 
NCP>SET NO 7.129 NAME ANYNAM<RET> 

9:43:10 NCP 
Request # 281; Set Node Completed 
NCP>SHOW NODE 7.129<RET> 
NCP> 

9:43:14 NCP 
Request # 282; Show Node Summary Completed 
Remote Node = 7.129 (ANYNAM) 

No information 

Remarks: 

DECnet-10 does not support the SET NODE NAME command for the 
executor. (The failure of Request # 280 in the example 
illustrates this.) 

Node names are of local significance only. If used in a command 
addressed to the network, the node address is substituted (using 
a table lookup) for the name. This mapping is transparent to the 
user. Thus, although the network recognizes nodes by address 
only, the operator has the convenience of using either nodename 
or nodeaddress (except for the few commands where one or the 
other is specifically noted) . 
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Command 

(set ) 

pEFINE( 



Entity 

NODE node id I 
EXECUTOR I 



Keyword/Argument 

ADDRESS node-address 

AREA MAXIMUM COST number 

AREA MAXIMUM HOPS number 

BROADCAST ROUTING TIMER seconds 

BUFFER SIZE bytes 

CONSOLE LOAD FILE file- id 

CONSOLE SECONDARY LOADER file-id 

COUNTER TIMER seconds 

CPU cputyp 

DELAY FACTOR number 

DELAY WEIGHT number 

DIAGNOSTIC FILE file-id 

DUMP ADDRESS number 

DUMP COUNT number 

DUMP FILE fileid 

HARDWARE ADDRESS eth-address 

HOST nodeid 

IDENTIFICATION idstring 

INACTIVITY TIMER seconds 

INCOMING TIMER seconds 

LOAD FILE fileid 

MAXIMUM ADDRESS number 
f MAXIMUM AREA number 
< MAXIMUM BROADCAST NONROUTERS number 

MAXIMUM BROADCAST ROUTERS number 

MAXIMUM BUFFERS number 

MAXIMUM COST number 

MAXIMUM HOPS number 

MAXIMUM CIRCUITS number 

MAXIMUM LINKS number 

MAXIMUM VISITS number 

OUTGOING TIMER seconds 

RETRANSMIT FACTOR number 

ROUTING TIMER seconds 

SECONDARY DUMPER file-id 

SECONDARY LOADER file-id 

SEGMENT BUFFER SIZE bytes 

SERVICE DEVICE devtype 

SERVICE CIRCUIT cktid 

SERIVCE NODE VERSION node-version 

SERVICE PASSWORD password 

SOFTWARE IDENTIFICATION fileid 

SOFTWARE TYPE sftyp 

STATE state 

SUBADDRESSES subaddress-range 

TERTIARY LOADER fileid 

TYPE nodtyp 



Function 



This command sets the volatile or permanent parameters 
node identified as nodeid or set as executor. 



for the 
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Arguments : 

ADDRESS node-address 

Specifies the address of the node to which you want the 
database entry to refer. The format of the node address is: 

area-number .node-number 

where the area-number is in the range 1-63 and the 
node-number is in the range 1-255 for DN20 nodes and 1-1023 
for Ethernet nodes. 

AREA MAXIMUM COST number 

This parameter applies only if the executor node is of type 
AREA. 

Sets the maximum total path cost allowed from the executor 
to any other level 2 routing node. The value is the maximum 
cost of circuits on the longest path between level 2 
routers. Number is a decimal in the range 1-1022. 

AREA MAXIMUM HOPS number 

This parameter applies only if the executor node is of type 
AREA. 

Sets the maximum number of routing hops allowable from the 
executor to any other level 2 routing node. Number is a 
decimal in the range 1-30. 

The AREA MAXIMUM COST and AREA MAXIMUM HOPS parameters are 
used to determine whether an area is reachable. In effect, 
AREA MAXIMUM HOPS and AREA MAXIMUM COST control the total 
possible path between areas in the network. 

BROADCAST ROUTING TIMER seconds 

This parameter applies to the executor node only. 

Specifies the maximum amount of time allowed between routing 
updates on Ethernet circuits. When the timer expires before 
a routing update occurs, a routing update is forced. The 
routing update produces a routing configuration message for 
each adjacent node. Routing uses this timer to enforce a 
maximum delay between routing updates. You can specify a 
number in the range 1 to 65535. The default value is 40, 

BUFFER SIZE bytes 

This parameter applies to the executor node only. This 
means that entity must be executor or nodeid must refer to 
the executor. If the executor has not been specified, 
executor defaults to the node where NCP is running. 

Sets the actual size of all circuit buffers, including 
protocol overhead. Size is a decimal number in the range 
1-65535. 
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For DECnet-10 nodes, the permitted range is 290-576 for DN20 
circuits and 290-1467 for Ethernet circuits. The default is 
576 bytes. This value must be 576 to support all DIGITAL 
operating systems. For a KL10 with a DN20 MCB, the buffer 
size must be equal or greater than 2 * MAXIMUM ADDRESS + 5. 
The buffersize for all nodes in the network must be the 
same. 

This value cannot be set for DECnet-10. It must be 
configured at installation (refer to the TOPS-10 DECnet and 
PSI Installation Guide) . 

CONSOLE LOAD FILE file-id 

This parameter applies to Ethernet communications servers. 

Identifies the file containing the software for downline 
loading remote console software into an Ethernet 
communications server. 

CONSOLE SECONDARY LOADER file-id 

This parameter applies to Ethernet communications servers. 

Identifies the file containing the secondary boot loader for 
downline loading remote console sofware into an Ethernet 
communications server. 

COUNTER TIMER seconds 

This parameter applies to all nodes except loop nodes. 

Seconds is a decimal integer in the range 1-65535. Counter 
timer is a Network Management Timer. When the seconds 
indicated have elapsed, the node counters are recorded as 
data in a logging event, and then zeroed. The logging 
begins again, and the log-record-zero cycle continues as 
long as the remote node communicates with the local node, or 
until the counter is cleared. The counter timer value must 
be set for the circuit counters to be automatically logged. 

CPU cputyp 

This parameter applies to adjacent nodes only. Identifies 
the node's CPU type as one of the following: 

DECSYSTEM-1020 

PDP-8 

PDP-11 

VAX- 11 

TOPS-10 supports loading of DN20 and Ethernet nodes 
(executor must be the KL10 node). Refer to the appropriate 
manuals to determine CPU types that can be downline loaded 
by non-DECnet-10 nodes that are acting as executors in your 
network. 
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DELAY FACTOR number 

This parameter applies to the executor node only. 

Sets the number used as a multiplier in an NSP algorithm 
that determines when to retransmit a message. The delay 
factor is multiplied by 1/16 of the round trip delay to set 
the retransmission timer to that node. The default value 
for DECnet-10 is 48. Number is a decimal number in the 
range 1-255. The larger the value of number, the longer the 
delay before retransmission. 

DELAY WEIGHT number 

This parameter applies to the executor node only. 

This parameter is used as a weighting factor when updating 
the estimated round trip delay to a node. Number is a 
decimal in the range 1-255. This value is initialized 
during network generation but can be modified by Network 
Management. The default for DECnet-10 is 10. 

DIAGNOSTIC FILE file-id 

This parameter applies to adjacent nodes on Ethernet 
circuits. 

Identifies the file to read from when the adjacent node is 
down-line loaded, and has requested diagnostics. The 
file-id is the name of the diagnostics file in the volatile 
data base that the target node can read. 

DUMP ADDRESS number 

This parameter applies to adjacent nodes only. 

Sets the memory address where the upline dump of an adjacent 
node is to begin. This parameter value is not supported for 
DECnet-10 nodes because a full dump is always taken. 

DUMP COUNT number 

Sets the default number of memory units to upline dump from 
the adjacent node specified. This parameter value is not 
supported for DECnet-10 nodes because a full dump is always 
taken. 

DUMP FILE fileid 

This parameter applies to adjacent nodes only. 

Identifies the file to receive the upline dump. 

HARDWARE ADDRESS eth-address 

Identifies the Ethernet address originally assigned to the 
Ethernet controller for the system. This address is 
necessary for communication with the system (for such 
purposes as down-line loading) . Eth-address is a string of 
12 hexadecimal digits, represented by 6 bytes separated by 
hyphens. 
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HOST nodeid 

This parameter applies to an executor node or an adjacent 
node. 

For the executor, identifies the node from which the 

executor requests services. For an adjacent node, it is the 

node providing service. If no host is specified, the 
default is the executor node, 

IDENTIFICATION idstring 

This parameter applies to the executor node only. 

Sets the text identification string for the executor, for 
example, "Development System" or "Research Lab," Idstring is 
an arbitrary string of 1-32 characters. An idstring 
containing blanks or tabs must be enclosed in quotation 
marks; two adjacent quotation marks indicate a quotation 
mark within a quoted string. The default for DECnet-10 is 
the system name set during the installation procedure. 

INACTIVITY TIMER seconds 

This parameter applies to the executor node only. 

The value in seconds determines the maximum time allowed to 
elapse with no activity in a logical link. When the number 
of seconds specified have elapsed, NSP tests the link with 
artificial traffic. The default for DECnet-10 is 120. 

INCOMING TIMER seconds 

This parameter applies to the executor node only. 

Sets a timeout value for incoming connects. If the connect 
is not accepted or rejected by the user within the number of 
seconds specified. Session Control rejects it for the user. 
Seconds is a decimal number in the range 1-65535. The 
default for DECnet-10 is 30. 

LOAD FILE file-id 

This parameter applies to an adjacent node only. 

Sets the file identification of the file to read when the 
node is downline loaded. File-id is in the format required 
by the executor's file system. 

MAXIMUM ADDRESS number 

This parameter applies to the executor node only. 

Sets the largest node address and, thus determines the 
greatest number of nodes that can be addressed by the local 
node. Number is a decimal value in the range 1-1023 for 
Ethernet communications, and 1-255 for DN20 communications. 
The default is 1023, Lowering this value will decrease 
system memory usage, therefore use the smallest number 
possible. 

This value cannot be set for DECnet-10. It must be 
configured at installation (refer to the TOPS-10 DECnet and 
PSI Installation Guide ) . 
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MAXIMUM AREA number 

This parameter is not implemented for DECnet-10, and it 
applies only if the executor node is of type AREA, 

Sets the largest area number, and thus is the number of 
areas that can be known about by the executor node's Routing 
layer. Number is an integer in the range 1-63. If this 
parameter is not specified, the Routing layer will 
recongnize up to 63 areas. 

MAXIMUM BROADCAST NONROUTERS number 

This parameter is the maximum number of nonrouting nodes 

(end nodes) that the executor node can recognize on its 

Ethernet circuits. Number is an integer in the range 
0-65535. The default for DECnet-10 is 64. 

MAXIMUM BROADCAST ROUTERS number 

This parameter is the maximum number of routers the executor 
node can recognize on its Ethernet circuits. Each routing 
node can be either a level 1 router (capable of routing 
within its own area, if area routing is specified) or a 
level 2 router (capable of routing within its own area and 
outside of its area). Number is an integer in the range 
0-65535. The default for DECnet-10 is 32. 

MAXIMUM BUFFERS number 

This parameter applies to the executor node only. 

Sets the total number of buffers allocated to all circuits. 
Routing uses this number to determine the size c»f its buffer 
pool . 

This parameter applies to the DN20 MCB node only and cannot 
be set by the operator or system manager. It is generated 
with NETGEN and can be changed only by repeating the NETGEN 
procedure (see the TOPS-10 DECnet and PS I Installation 
Guide) . You can display MAXIMUM BUFFERS when you type the 
NCP command SHOW EXECUTOR CHARACTERISTICS when the executor 
is the MCB front end. 

MAXIMUM CIRCUITS number 

This parameter applies to the executor node only. 

Sets the maximum number of circuits that this node can 
support in the network. Number is a decimal number in the 
range 1-20. The default is 16. 

This parameter applies to the DN20 MCB node only and cannot 
be set by the operator or system manager. MAXIMUM CIRCUITS 
is displayed in response to the SHOW EXECUTOR 
CHARACTERISTICS NCP command when the executor is the DN20 
MCB node. 
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MAXIMUM COST number 

This parameter applies to the executor node only. 

Sets the maximum total path cost allowed from the executor 
to any node. Path cost is the sum of the circuit costs 
along a path between two nodes. If the path cost is greater 
than the MAXIMUM COST, the node is considered unreachable. 
Number is a decimal in the range 1-1022. The default for 
DECnet-10 is 100. 

MAXIMUM HOPS number 

This parameter applies to the executor node only. 

Sets the maximum number of hops between any two nodes in the 
network. If the number of hops is greater than the MAXIMUM 
HOPS, the node is considered unreachable. Number is a 
decimal number in the range 1-30, The default for DECnet-10 
is 16. 

MAXIMUM LINKS number 

This parameter applies to the executor node only. 

Sets the maximum allowable active logical link count for the 
node. Number is a decimal in the range 1-65535. 

This parameter applies to the DN20 MCB node only and cannot 
be set by the operator or system manager. MAXIMUM LINKS is 
displayed in response to the SHOW EXECUTOR CHARACTERISTICS 
NCP command when the executor is the DN20 MCB node, 

MAXIMUM VISITS number 

This parameter applies to the executor node only. 

Sets the maximum number of nodes a message coming into this 
node can have visited. If the number specified is exceeded 
and the destination is not for this node, the message is 
discarded. Number is a decimal number that cannot be less 
than MAXIMUM HOPS. The upper limit is 63. The default for 
DECnet-10 is 20. 

OUTGOING TIMER seconds 

This parameter applies to the executor node only. 

Sets a timeout value for outgoing connects. If the time 
between the request of a connect and the acknowledgement of 
the request is greater than the specified seconds. Session 
Control returns an error. Seconds is a decimal number in 
the range 1-65535. The default for DECnet-10 is 60. 

RETRANSMIT FACTOR number 

This parameter applies to the executor node only. 

Sets the number of times the source NSP will retransmit a 
timed-out message. If the value of number is exceeded, NSP 
reports to Session Control a loss of confidence for this 
logical link. In DECnet-10, Session Control then aborts the 
logical link. The default for DECnet-10 is 10. 
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ROUTING TIMER seconds 

This parameter applies to the executor node only. 

Sets the number of seconds between transmissions of routing 
messages on non-Ethernet circuits. 

Routing update messages contain information about the cost 
and hops to each node in the network. These messages are 
sent automatically whenever there is a change in the 
information (for example, when a line goes down). In 
addition, routing update messages are sent periodically by 
the routing timer. These periodic transmissions ensure that 
routing tables are kept up to date in the unlikely event 
that a routing update message is lost. 

Seconds is a decimal in the range 1-65535. The default for 
DECnet-10 is 600. 

SECONDARY DUMPER fileid 

This parameter applies to adjacent nodes only. 

Identifies the secondary dumper file to be used for upline 
dumping the adjacent node. See Section 4.5.8, Specifying 
Files. 

SECONDARY LOADER fileid 

This parameter applies to adjacent nodes only. 

Identifies the secondary loader file to be used for downline 
loading the adjacent node. 

SEGMENT BUFFER SIZE bytes 

For DECnet-10, the value of this parameter is equal to the 
value set for BUFFERSIZE; SEGMENT BUFFER SIZE cannot be 
changed. 

Sets the maximum size of the end-to-end segment. This size 
includes protocol overhead down to and including the End 
Communication layer, plus a constant value of 6 (for 
compatibility with the BUFFER SIZE parameter definition). 
The size does not include the Routing or Data link overhead 
(except for the constant value of 6) . 

The size is in bytes, and is a decimal integer in the range 
256-576. 

SERVICE CIRCUIT cktid 

This parameter applies to adjacent nodes only. 

Sets the circuit to be used to the adjacent node for 
downline loading or upline dumping. For downline loading 
the NODE node parameter must be the target (adjacent) node. 
(See Section 7.3.2 for an explanation of cktid.) 
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SERVICE DEVICE devtype 

This parameter applies to adjacent nodes only. 

Sets the service device type the adjacent node uses when in 
service slave mode (MOP protocol) • The value typed for 
devtype is one of the standard line device mnemonics. The 
options are the following: 



CI 


CNA 


DA 


DL 


DLV 


DMC 


DMF 


DMP 


DMR 


DMV 


DN 


DP 


DPV 


DQ 


DTE 


DU 


DUP 


DV 


DZ 


ETH 


KDP 


KDZ 


KL 


KMY 


KMX 


NI 


PCL 


QNA 


UNA 









See Appendix F for a description of DECnet line devices. 

DECnet-10 does not require the device type before using a 
LOAD command; however, if devtype is set, the system 
verifies that the node is associated with the named device. 

SERVICE NODE VERSION node-version 

Specifies the DECnet-10 software version of the node which 
downline loads its software to the target node. Version is 
the number 1 for Phase IV and for previous versions. The 
default value is 1 (Phase IV) , 

SERVICE PASSWORD password 

This parameter applies to adjacent nodes only. 

Sets the password required to trigger the bootstrap 
mechanism on the adjacent node. Password is a hexadecimal 
number. For DDCMP circuits, the range is to FFFFFFFF; for 
Ethernet circuits the range is to FFFFFFFFFFFFFFFF. 

SOFTWARE IDENTIFICATION softwareid 

This parameter applies to adjacent nodes only. 

Sets any descriptive string that will identify the software 
to be loaded when the adjacent node is downline loaded 
(example, DN20 files) . Softwareid contains up to 16 
alphanumeric characters. 

SOFTWARE TYPE sftyp 

This parameter applies to adjacent nodes only. 

Identifies the initial software to be loaded in a downline 
load operation as one of: 

SECONDARY LOADER 
TERTIARY LOADER 
SYSTEM 
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STATE state 

For EXECUTOR node: (Not implemented by DECnet-10) 

ON 

OFF 

SHUT 

RESTRICTED 

(See Section 7.3.3 for definition of these parameter 

values.) 

For Remote nodes: (Not implemented by DECnet-10) 

REACHABLE 

UNREACHABLE 

(See Section 7.3.3 for definition of these parameter 

values.) 

TERTIARY LOADER file id 

This parameter applies to adjacent nodes only. 

Identifies the tertiary loader file to be used for downline 
loading the adjacent node. 

TYPE nodtyp 

This parameter applies to the executor node only. NML 
parses the command, but TYPE cannot be set for DECnet-10. 
If a node other than a TOPS-10 node is to execute this 
command, consult the appropriate documentation. Type is one 
of: 

AREA-ROUTER 

NONROUTING-III 

NONROUTING-IV 

ROUTING-III 

ROUTING-IV 

Examples : 

1. Set the name of node 5.14 to AURORA: 

NCP>SET NODE 5.14 NAME AURORA 

2. Set the default processor type to be downline loaded: 

NCP>SET NODE BANGOR SOFTWARE INDENTIFICATION - 
RSX-11S-V3.2 

Remarks: 



As a user with operato 
value (or several val 
get a response specifi 
good practice to resto 
NCP. If you feel that 
system manager or i 
parameter values that 
are acceptable under 
understand the probabl 
For example, it is s 
specification before c 



r privileges, if you change a parameter 
ues) to improve a temporary condition or to 
c to your own requirements, it is usually 
re the original setting before exiting from 
the change should remain, consult your 
nform other users by message. The default 
are present when the system is brought up 
normal conditions. Be sure that you 
e effect of any change before you make it. 
trongly suggested that you refer to the NSP 
hanging DELAY FACTOR or DELAY WEIGHT. 
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Command 

I SET ) 
I DEFINE j 

Function: 



Entity 
KNOWN NODES 



Keyword/Argument 
(all 

) COUNTER TIMER seconds 



SET KNOWN NODES ALL loads all node parameter values from the 
permanent data base into the volatile data base (this command is 
not supported by DECnet-10) . Other SET KNOWN NODES commands set 
the specified value in the volatile data base of each node known 
to the executor. Note that many values that can be set for one 
node do not apply logically to KNOWN NODES. 

Arguments: 

See SET/DEFINE NODE (singular) . 

Examples: 

1. Set the node logging event for all known nodes to take place 
every 600 seconds: 

NCP>SET KNOWN NODES COUNTERS 600 

Remarks : 

On the DN20 MCB node, setting COUNTER TIMERS for KNOWN NODES is 
very demanding on NML resources and should be avoided if not 
necessary. 



7.5.6 SET/DEFINE LOGGING 

Command Entity 

SET I (logging sinktypel 
DEFINE) (KNOWN LOGGING ) 



Keyword/Argument 

ALL 

EVENT eventlist [sourcequal] [sinknode] 

KNOWN EVENTS [sourcequal] [sinknode] 

NAME sinkname 

STATE sinkstate 



Function: 



Used to control where events are logged (event sinks) and which 
events get logged, (the DECnet-10 default is all events logged 
to SYS: ERROR. SYS.) 
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Arguments: 



See Section 7.3.6 for sinktype, eventlist, and sinkstate. See 
Table 7-1 in the same section for the relationship between class 
and entity required for sourcequal. 

NAME sinkname 

Identifies the name of the console, file, or monitor program 
to which events will be logged: 

If sinktype is CONSOLE, enter device name 

If sinktype is FILE, enter file name 

If sinktype is MONITOR, enter identification string for 

the monitoring program 

DECnet-10 does not support the MONITOR sink. 

sourcequal 

This argument selects a specific entity according to event 
classes. The format is: 

AREA area-id 
CIRCUIT ckt-id 
LINE line-id 
MODULE type 
NODE node- id, 

sinknode 

Specifies a node that receives events in format: SINK NODE 
nodeid or SINK EXECUTOR. 



Examples : 



Cause all events generated locally to be logged to the 
logging console on remote node TOSCA. 

NCP>SET LOGGING CONSOLE KNOWN EVENTS SINK NODE TOSCA 

Cause all class 5 events for line ETH-0 to be logged on the 
CONSOLE 

NCP>SET LOGGING CONSOLE EVENT 5.* LINE ETH-0 



7.6 CHANGING NETWORK DATA BASES: CLEAR AND PURGE COMMANDS 

The CLEAR command clears parameters from the volatile data base; for 
systems that support a permanent data base, the PURGE command clears 
parameters from the permanent data base. The entities are the same as 
the entities for the SET and DEFINE commands. However, not all 
parameters can be purged or cleared by executing commands that specify 
individual parameter values. The allowed parameter keywords are, 
therefore, a subset of the SET/DEFINE keywords. Except for the 
LOGGING entity, you need not supply values for keywords. 

Refer to the arguments for the SET/DEFINE commands if you need to 
refresh your memory on restrictions and exact meaning of keywords. 
Complete information follows for only those commands that require 
further description. 
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Command 



Entity 



Keyword/Argument 
:li{ 
(name sinkname 



clear) LOGGING sinktype (EVENT eventlist [sourcequal] [sinknode] 
PURGE? {known EVENTS [sourcequal] [sinknode] 

Function: 



Together with the SET/DEFINE LOGGING commands, these commands 
control the logging of events: both the events that will be 
logged and where they will be logged. 

Arguments: 

Refer to Section 7.3,6 for details. 



Command 

I CLEAR I 
I PURGE j 



Entity 

(circuit cktid 
) KNOWN CIRCUITS 



CLEAR 
PURGE 



I CLEAR 
[PURGE 



(line lineid) 
I KNOWN LINES? 



(NODE node id) 
I KNOWN NODES) 
(EXECUTOR can be 

substituted for 

nodeid .) 



Key word/ Argument 

(ALL ) 

{counter TIMER) 

(owner ) 

For systems supporting multipoint: 
' ACTIVE/INACTIVE/DYING BASE 
ACTIVE/INACTIVE/DYING INCREMENT 
BABBLE TIMER 

INACTIVE/DYING/DEAD THRESHOLD 
I MAXIMUM BUFFERS 
MAXIMUM TRANSMITS 
TRANSMIT TIMER 

/ALL \ 

(COUNTER TIMER) 

For systems supporting multipoint: 
DEAD/DELAY/SCHEDULING/STREAM TIMER 

ALL 

CIRCUIT 

CONSOLE LOAD FILE 

CONSOLE SECONDARY LOADER 

COUNTER TIMER 

CPU 

DUMP ADDRESS 

DUMP COUNT 

DIAGNOSTIC FILE 

DUMP FILE 

HARDWARE ADDRESS 

HOST 

IDENTIFICATION 

INCOMING TIMER 

LOAD FILE 

NAME 

OUTGOING TIMER 

SECONDARY DUMPER 

SECONDARY LOADER 

SERVICE DEVICE 

SERVICE CIRCUIT 

SERVICE PASSWORD 

SOFTWARE IDENTIFICATION 

SOFTWARE TYPE 

TERTIARY LOADER 
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Function: 

The CLEAR and PURGE commands remove the volatile and permanent 
values, respectively, from the specified entity. 

Arguments: 

None. (You specify the keyword only.) 

Examples : 

With the exception of CLEAR EXECUTOR to change the executor from 
a remote node to the TOPS-10 node, and the CLEAR NODE command to 
remove a loopnode NAME, you will have little use for the CLEAR 
command. (These two uses have been shown.) It is not necessary 
to CLEAR a parameter value for an entity to change it. Using the 
SET command to establish the new value is sufficient. However, 
in the case of changing a node name, you must remove the node 
name before setting the new name, for example: 

NCP>CLEAR NODE 255 NAME 
NCP>SET NODE 255 NAME GOOSE 

Remarks: 

DECnet-10 does not support the CLEAR command for the following 
parameters: 

For CIRCUITS 

OWNER 

Multipoint parameters 

X.25 parameters 

For LINES 

ALL 

Multipoint parameters 

X,25 parameters 

For NODES 

DUMP ADDRESS 

DUMP COUNT 

NAME (not for EXECUTOR) 

X.25 parameters 

Multipoint parameters 
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7.7 MONITORING THE NETWORK: LIST AND SHOW COMMANDS 

NCP provides commands to display information about network components, 
in the volatile and permanent database (DECnet-10 V4.0 does not 
support the permanent database) . SHOW displays information about 
components for the running network. LIST performs a similar function, 
but lets you display and verify information in the permanent database. 

The SHOW and LIST commands allow you to select components and display 
types. You can choose from the following display types. 



CHARACTERISTICS 



Includes parameters that remain constant 
until cleared or reset. For example, timer 
values and buffer sizes. 



COUNTERS 



EVENTS 



Provides error and performance statistics. 
For example, logical links in use. 

Includes information about events currently 
being logged by the logging entity. Logged 
events aid in detecting failures and 
isolating problems. 



This display type is valid only for the SHOW 
LOGGING and LIST LOGGING commands. 



STATUS 



Includes dynamic information that usually 
reflects network operations for the running 
network. 



SUMMARY 



Includes only the most useful information 
from CHARACTERISTICS and STATUS display 
types. 



If you do not specify a display type 
command, SUMMARY is the default. 



when issuing a SHOW or LIST 
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Command 

(list) 

iSHOW( 



Function: 



Entity 

ACTIVE AREAS 
AREA area number 
KNOWN AREAS 



ACTIVE CIRCUITS) 
CIRCUIT cktid > 
KNOWN CIRCUITS ) 



ACTIVE LINES 
KNOWN LINES 
LINE lineid 

ACTIVE MODULES 
KNOWN NODULES 
EXECUTOR 
ACTIVE NODES 
KNOWN NODES 
LOOP NODES 
NODE nodeid 

ADJACENT NODES 



ACTIVE LOGGING 
KNOWN LOGGING 
LOGGING sink-type 



MODULE CONSOLE 



Keywo rd/ Arg ument 

characteristics) 
counters ( 

STATUS ( 

SUMMARY j 

CHARACTERISTICS 
COUNTERS 
STATUS 
SUMMARY 

.characteristics 
'counters 

STATUS 
SUMMARY 



Qualifier 



[ADJACNET NODE nodeid] 



i| 



CHARACTERISTICS 
COUNTERS 
STATUS 
SUMMARY 

CHARACTERISTICS 

EVENTS 

STATUS 

SUMMARY 



[CIRCUIT cktld] 
[KNOWN CIRCUITS] 



[SINK NODE nodeid] 
[KNOWN SINKS] 



/CHARACTERISTICS^ 
(SUMMARY / 



MODULE CONFIGURATOR /STATUS \ 

(SUMMARY/ 



[KNOWN CIRCUITS] 
[CIRCUIT Cktid] 



MODULE LOADER) 
MODULE LOOPERj 

QUEUE 



/STATUS \ 
(SUMMARY I 



The SHOW command displays information from the volatile data 
base; the LIST command displays information from the permanent 
data base. 
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Examples: 

NCP>SHOW KNOWN CIRCUITS COUNTERS<RET> 

6:32:38 NCP 

Set Executor Complete 
NCP> 
6:34:14 NCP 

Request # 262 Accepted 
NCP> 

6:34:15 NCP 

Request # 262; Show Known Circuits Counters Completed 

Circuit = DTE-0-1 



6423 Seconds Since Last Zeroed 

7272 Terminating Packets Received 

9027 Originating Packets Sent 

Terminating Congestion Loss 

6701 Transit Packets Received 

7186 Transit Packets Sent 

Transit Congestion Loss 

Circuit Downs 

Initialization Failures 

852561 Bytes Received 

510678 Bytes Sent 

14361 Data Blocks Received 

16220 Data Blocks Sent 



Circuit = DMC-0 

2468 Seconds Since Last Zeroed 

Terminating Packets Received 

Originating Packets Sent 

Terminating Congestion Loss 

1615 Transit Packets Received 

1615 Transit Packets Sent 

Transit Congestion Loss 

1 Circuit Downs 

Initialization Failures 

17910 Bytes Received 

230124 Bytes Sent 

1233 Data Blocks Received 

1615 Data Blocks Sent 

Data Error Inbound 

Data Errors Outbound 

Remote Reply Timeouts 

Local Reply Timeouts 

Remote Buffer Errors 

Local Buffer Errors 

Selection Intervals Elapsed 

Selection Timeouts 
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Example 2: 

.R OPR<RET> 

OPR>ENTER NCP<RET> 

NCP>SHOW ACTIVE NODES CHARACTERISTICS<RET> 

NCP> 

16:41:51 NCP 

Request # 307 Accepted 
NCP> 

16:42:00 NCP 

Request # 307; Show Active Nodes Characteristics Completed 
Executor Node = 7.123 (COURT) 

Identification = DECnet-10 Version 4.0 

Management Version = 4.0.0 

Host = 7.113 (KINGS) 

Loop Count = 1 

Loop Length = 127 

Loop With = Mixed 

Incoming Timer = 10 

Outgoing Timer = 30 

NSP Version = 4.0.0 

Maximum Links = 8 

Delay Factor = 2 

Delay Weight = 3 

Inactivity Timer = 30 

Retransmit Factor = 5 

Routing Version = 2.0.0 

Type = Routing IV 

Routing Timer = 60 

Maximum Address = 255 

Maximum Circuits = 8 

Maximum Cost = 100 

Maximum Hops = 16 

Maximum Visits = 32 

Maximum Broadcast Nonrouters = 64 

Maximum Broadcast Routers = 32 

Maximum Buffers = 66 

Buffer Size = 576 

Segment Buffer Size = 576 

Remote Node = 7.113 (KINGS) 

No Information 
Remote Node = 7.118 () 

No Information 

NCP>EXIT<RET> 

Remarks: 

SHOW or LIST entity with no information type (carriage return 
follows plural entity or entity entityid) will default to 
SUMMARY. 

To successfully display STATE, STATUS, SUMMARY, CHARACTERISTICS, 
or COUNTERS for all DN20 lines and circuits, you must set the 
executor to the communications front end (DN20) . The KL10 
recognizes the DTE as the path it uses to load and dump the DN20. 
The characteristic needed to perform a dump or load is SERVICE 
ENABLED. 
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7,8 CONTROLLING THE NETWORK; DUMP, LOAD, LOOP, AND TRIGGER COMMANDS 

The following section describe the commands for controlling the nodes 
in the network. 



7.8,1 DUMP 

Command Entity Keyword/Argument 

DUMP NODE nodeld [VIA cktid] 

[DUMP COUNT number] 
[PHYSICAL ADDRESS eth-address] 
[SECONDARY [DUMPER] fileid] 
[SERVICE DEVICE devtype] 
[[SERVICE] PASSWORD password] 
[TO dumpfileid] 

Function: 

Stores a copy of the target's memory image in a dump file at the 
host node. 

Arguments: 

VIA cktid 

Identifies the circuit used for the dump. 

TO dumpfileid 

Identifies the host's file to receive the target's dump. 

All other parameters and arguments are described in Section 
7.5.3, the SET/DEFINE NODE nodeid command. 

Example: 

Copy the memory image of the DN20 node JAZZ to the host node, 

NCP>DUMP NODE JAZZ<RET> 

Remarks: 

This command is not needed to obtain a dump when the DN20 is 

automatically reloaded. The dump is also automatic. However, 

there may be times you wish to dump the MCB front end when an 
automatic dump/load procedure is not indicated. 

Before dumping the DN20, execute the NCP command SET CIRCUIT 
DTE-0-1 SERVICE ENABLED, if necessary, (The circuit you enable 
is the circuit connecting the host and target node.) 
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Command Entity Keyword/Argument 

DUMP VIA cktid [[DUMP] ADDRESS number] 

[[DUMP] COUNT number] 
[PHYSICAL ADDRESS eth-address] 
[SECONDARY [DUMPER] fileid] 
[SERVICE DEVICE devtype] 
[[SERVICE] PASSWORD password] 
[TO dumpfileid] 

Function and arguments as for DUMP NODE nodeid. 

Remarks : 

The DN20 should not require this command. The SERVICE CIRCUIT 
for the DN20 is setup automatically when initial values are read 
from a command file at system startup. 

The VIA cktid parameter and argument in the entity position is 
simply a more descriptive way of indicating the entity circuit. 

DECnet-10 software normally requires no parameters; that is, the 
commands shown in the examples are executed under normal 
conditions. The node data base for the host node contains the 
needed dump parameter values when the system is brought up. If a 
needed parameter value is missing, the NCP response names the 
missing parameter. Use the SET NODE command to enter the missing 
parameter and repeat the DUMP NODE command. 



7,8.2 LOAD 

Command Entity 

LOAD (node nodeid 
iviA cktid 



Keyword/Argument 

[ADDRESS nodeaddr] 

[CPU type] 

[FROM loadfileid] 

[HOST nodeid] 

[NAME nodename] 

[PHYSICAL ADDRESS eth-address] 

[SECONDARY [LOADER] fileid] 

[SERVICE CIRCUIT cktid] 

[SERVICE DEVICE devtype] 

[SERVICE NODE VERSION node-version] 

[[SERVICE] PASSWORD password] 

[SOFTWARE IDENTIFICATION softwareid] 

[SOFTWARE TYPE type] 

[TERTIARY [LOADER] fileid] 

[VIA cktid] (Not applicable if command is 

LOAD VIA cktid.) 



Function: 



The LOAD command allows one node in the network to load the 
system image file to a remote node in the network. (See Remarks 
for conditions and restrictions.) 
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NOTE 

All parameters and arguments for the LOAD command are 
optional (with the exception of the PHYSICAL ADDRESS 
parameter, which must be specified with the LOAD VIA 
command) . This is because the permanent data base 
contains values used as defaults by systems supporting 
a permanent data base. In DECnet-10, the values used 
are those initial values established as the volatile 
data base at system startup. You type only those 
keywords and values that you need to change. (For 
example, if you wish to load the DN20 with an 
alternate load file, you type an alternate filename.) 

In DECnet-10, any missing parameters are indicated in 
an error message, and can be set at that time and the 
command re-tried. 

Arguments J 

VIA cktid 

Identifies the circuit over which to load. 

ADDRESS nodeaddr 

Nodeaddr is the address the target node is to use when it 
initializes. 

CPU type 

This is the target CPU type. See Section 7.3.3 for 
predefined arguments. 

FROM loadfileid 

Identifies the image file to be loaded. 

HOST nodeid 

Sends the target node the nodeid of the host node that will 
provide services (such as a file system) for the target node 
once it is loaded. Note that this may or may not be the 
same node as the executor. If HOST nodeid is not specified, 
the executor is assumed to be the host node of the target 
node. 

NAME nodenarae 

Specifies the name of the target node. 

PHYSICAL ADDRESS eth-address 

Identfies the Ethernet address. This parameter is required 
in the LOAD VIA command and is optional in the LOAD NODE 
command. 

SECONDARY [LOADER] fileid 

Identifies the secondary loader file; that is, the file to 
be requested by the primary loader (contained in the target 
bootstrap) . 
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SERVICE DEVICE devtype 

Identifies the target node's line controller for the service 
line over which the operation is to take place. The options 
are the following: 



CI 


CNA 


DA 


DL 


DLV 


DMC 


DMF 


DMP 


DMR 


DMV 


DN 


DP 


DPV 


DQ 


DTE 


DU 


DUP 


DV 


DZ 


ETH 


KDP 


KDZ 


KL 


KMY 


KMX 


NI 


PCL 


QNA 


UNA 









See Appendix F for a description of DECnet line devices. 

SERVICE NODE VERSION node-version 

This parameter is the DNA version of the adjacent node, 

which is used to determine the TARGET SYSTEM ADDRESS 

parameter in the MOP Parameter Load with Transfer Address 

message. Phase IV is indicated by 1, and Phase III is 
indicated by 0. The default is 1, 

SERVICE PASSWORD password 

Identifies the password required to trigger the bootstrap 
mechanism on the target node. The password is a hexadecimal 
number. For DDCMP circuits, it is in the range 0-FFFFFFFF; 
for Ethernet circutis, it is in the range 
0-FFFFFFFFFFFFFFFF. The SERVICE keyword is optional. 

SOFTWARE IDENTIFICATION software type 

See Section 7.5.4, SET NODE nodeid command for descriptions 
of this keyword. 

SOFTWARE TYPE type 

See Section 7.5.4, SET NODE nodeid command for descriptions 
of this keyword. 

TERTIARY LOADER fileid 

Identifies the tertiary loader file (requested by the 
secondary loader file) for the target node. 

Examples : 

See Section 3.1 for examples. 
Remarks: 

See Section 3.1 for loading procedure. 
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7.8.3 LOOP 



Command 
LOOP 



Entity 



NODE node- id 
EXECUTOR 
LINE line-id 



CIRCUIT 



Keyword/Argument 

[USER user-id] [COUNT count] 
[ACCOUNT account] [LENGTH number] 
[PASSWORD password] [WITH ONES] 

ZEROS] 
MIXED] 

[ASSISTANT NODE node-id] 

[ASSISTANT PHYSICAL ADDRESS eth-address] 

[HELP help-type] 

[NODE node-id] 

[PHYSICAL ADDRESS eth-address] 



Function: 



This command tests a node, line, or circuit by transmitting test 
blocks of data. 



Arguments ; 



Access information (USER, ACCOUNT, and PASSWORD) refers to these 
values for the node named in NODE nodeid. If node is remote, the 
conventions of the remote node are used. 

COUNT count 

This parameter is the number of blocks to be sent during 
loopback testing. The count is a decimal integer in the 
range 1-65535. 

LENGTH number 

This parameter is the length (in bytes) of blocks to be sent 
during loopback testing. The length is a decimal integer in 
the range 1-65535. 

ONES 
WITH ZEROS 
MIXED 

This parameter specifies the content of the test data. The 
default is MIXED (a combination of ones and zeroes) . 

Arguments for CIRCUIT 

ASSISTANT PHYSICAL ADDRESS eth-address 

This parameter is not supported by DECnet-10. 

Identifies the Ethernet physical address of the node that 
will perform the role of loopback assistant for Ethernet 
third-party loop testing. ASSISTANT PHYSICAL ADDRESS must 
be specified if HELP is included in this command. The 
address cannot be a multicast address. Eth-address is a 
string of 12 hexadecimal digits, represented by 6 bytes 
separated by hyphens. This parameter can be used instead of 
the ASSISTANT NODE parameter. 



7-51 



NCP COMMANDS PROCESSED BY THE NETWORK MANAGEMENT LAYER 

ASSISTANT NODE node-id 

This parameter is not supported by DECnet-10, 

Identifies the name of the node or the address of the node 
that will perform the role loopback assistant for Ethernet 
third-party loop testing. This parameter can be used 
instead of the ASSISTANT PHYSICAL ADDRESS parameter. 

HELP help-type 

This parameter is not supported by DECnet-10. 

Indicates the amount of assistance to be provided during 
Ethernet loopback testing by the assistant node, whose 
address is specified in the ASSISTANT NODE ADDRESS or 
node-id as specified in the ASSISTANT NODE parameter. There 
are three possible values of help-type; 

TRANSMIT 

The assistant node relays the request to the 
destination node, which replies directly to the 
executor node. 



RECEIVE 



FULL 



The executor node sends the request directly to 
the destination node, which relays the reply to 
the assistant node for transmission to the 
executor node. 



The assistant node relays the request and the 
reply between the executor node and the 
destination node. 



NODE node-id 



Identifies the destination node to be used for loopback 
testing of the specified Ethernet circuit. Can be used 
instead of the PHYSICAL ADDRESS parameter. 

PHYSICAL ADDRESS eth-address 

Identifies the Ethernet physical address of the destination 
node to be used for loopback testing of the specified 
Ethernet circuit. Eth-address is a string of 12 hexadecimal 
digits, represented by 6 bytes separated by hyphens. 



Examples: 



1. Start an Ethernet circuit-level loopback test with a node 
whose Ethernet physical address is AA-00-04-00-FF-04. 

NCP>LOOP CIRCUIT ETH-0 PHYSICAL ADDRESS ^ 
AA-00-04-00-FF-04 
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Remarks: 



LOOP NODE (and LOOP CIRCUIT) are described in detail in Section 
3.7.1. 

DECnet-10 supports the LOOP CIRCUIT command for Ethernet lines 
only. 

If any of the three access parameters (USER, ACCOUNT, or 
PASSWORD) are typed, they must precede other optional parameters. 



7.8,4 TRIGGER 
Command Entity 
TRIGGER I NODE node id 

VIA cktid 
Function: 



Keyword/ Argument 

[PHYSICAL ADDRESS eth-address] 
[[SERVICE] PASSWORD password] 
[VIA cktid] 

PHYSICAL ADDRESS eth-address 
[[SERVICE] PASSWORD password] 



The TRIGGER command attempts to cause the target node (the node 
to be loaded) to send a load request to the executor. The 
executor must be an adjacent node. Use this command to initiate 
the loading sequence for an unattended system. 

Arguments : 

PHYSICAL ADDRESS eth-address 

This parameter is the Ethernet address currently in use for 
the target node. It is required in the TRIGGER VIA command 
and optional in the TRIGGER NODE command. 

[[SERVICE] PASSWORD password] 

This parameter specifies the password to trigger the target 
node. The entire parameter with its value is optional. If 
included, SERVICE (for clarity) may be included or omitted 
as an additional keyword. 



VIA cktid 



Identifies the circuit over which the operation is 
place. 



to take 
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Examples: 

1. Trigger node TRMSRV to initiate a downline load. 

NCP>TRIGGER NODE TRMSRV 

2. Trigger Ethernet node SWIFT to initiate a downline load. The 
executor node uses the Ethernet physical address to address 
SWIFT on Ethernet circuit ETH-0. 

NCP>TRIGGER NODE SWIFT PHYSICAL ADDRESS - 
AA-00-04-00-07-04 VIA ETH-0 

3. Provide a service password in order to trigger node NYC to 
initiate a downline load over circuit ETH-0, 

NCP>TRIGGER NODE NYC SERVICE PASSWORD - 
FEFEFEFFEFEFEFEPE VIA ETH-0 

Remarks: 

DECnet-10 V4.0 does not support the TRIGGER command for the DN20. 
Other target nodes, such as terminal servers, are supported. 



7.9 MONITORING NODE ACTIVITY; ZERO COMMAND 

Command Entity Keyword/Argument 

ZERO /circuit cktid \ COUNTERS 
KNOWN CIRCUITS 
EXECUTOR 
LINE lineid 
KNOWN LINES 
NODE nodeid 
KNOWN NODES 
KNOWN MODULES 

Function: 

The ZERO command resets the counters for the specified entity on 
the local node. 

Arguments : 

None - counters are considered as an aggregate. Individual text 
items, such as line down for line counters can not be addressed. 

Examples : 

1. Resets all node counters maintained on the local node for 
node AURORA. 

NCP>ZERO NODE AURORA COUNTERS 

2, Resets all circuit counters for all known circuits. 

NCP>ZERO KNOWN CIRCUIT COUNTERS 
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CHAPTER 8 
NETWORK MANAGEMENT PACKET SWITCHING INTERFACE 



If the PSI Version 1.0 software option is included in your TOPS-10 

system, your DECnet network supports the X.25 facility for using 

Public Packet Switching Networks (PPSNs) , You can then use the X.25 
NCP commands and parameters. 

If the PSI softeware option is not included in your TOPS-10 system, 
you DECnet network may include nodes of DIGITAL systems that support 
the X.25 facility for using PPSNs, The Network Management modules 
understand the syntax of X.25-related commands and parameters. You 
can, therefore, by using the TELL node-id prewfix or the SET EXECUTOR 
NODE node-id command, direct X,25-related commands to DECnet nodes 
that support a Packetnet System Interface (PSI) . 

This chapter contains a complete list of X.25-related NCP commands as 
specified by the DNA. As was true of the DECnet utility commands 
documented in previous chapters, the set of commands implemented, and 
the way in which they are implemented, is a function of the operating 
system of each node in the network. 



8.1 THE MODULE ENTITY 

You have already been introduced to five possible entities 
(controllable objects) that are addressable in Phase IV DECnet: 
NODES, LINES, CIRCUITS, LOGGING, and maintenance MODULE. With the 
addition of the X.25 facility, another entity is provided. This is 
the X.25 MODULE entity. The X.25 MODULE entity takes one of three 
forms: MODULE X25-ACCESS, MODULE X25-PROTOCOL, and MODULE X25-SERVER. 
The general nature of the information contained in the data bases 
associated with each is as follows: 

MODULE X25-ACCESS 

The access module data base contains the information needed 
to connect to one or more Public Packet Switching Networks 
(PPSNs) . The information is indexed by network name. NCP 
commands that reference this data base must indicate the 
name of the network to which the command applies unless 
there is only one netowrk name in the data base. This data 
base resides in the TOPS-10 host node. 
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MODULE X25-PROTOCOL 

The protocol module data base contains the information 
needed to maintain switched virtual circuits (SVCs) and 
permanent virtual circuits (PVCs) through the public data 
network. 

Much of the SVC information is indexed by the local Data 
Termination Equipment (DTE) address. This address is 
assigned by the PPSN at the time the line is installed. You 
must include this address whenever it is a parameter in an 
NCP command, unless it is the only DTE address in the data 
base. This data base resides in the gateway node. 

MODULE X25-SERVER 

The server module data base contains the information needed 
to map incoming calls to a DECnet process. This information 
is indexed by destination name. You must associate each 
destination name with a DECnet node and process 
identification and with the necessary X.25-related 
information to recognize the incoming call. NCP commands 
that reference this data base must indicate to which 
destination name they apply unless there is only one such 
name defined in the data base. This data base resides in 
the gateway node. 



8.2 X.25-SPECIFIC COMMANDS 

SET, CLEAR and SHOW refer to parameters in the volatile data base; 
DEFINE, PURGE, and LIST refer to parameters in the permanent data 
base. These three pairs are considered together in the detailed 
descriptions that follow. All other commands are described in 
separate charts. Remember that neither TOPS-10 nor the MCB supports a 
permanent data base. Therefore, only SET, CLEAR, and SHOW are used 
for TOPS-10 PSI, All commands are described because other operating 
systems may implement a permanent data base. 



Command 

SET ) 
DEFINE ? 



Entity 

(circuit cktid 
) KNOWN CIRCUITS 



Keyword/Argument 

MAXIMUM DATA bytecnt 

MAXIMUM WINDOW bloc ken t 

USAGE usagtyp 

BLOCKING blockcntl 

NUMBER callnum 

MAXIMUM RECALLS recallcnt 

RECALL TIMER seconds 

CHANNEL chnlnum 

DTE dteaddr 

TYPE X25 



In addition to the parameters that are X.25-specif ic, the following 
parameters are common to both DDCMP and X.25 circuits: COUNTER TIMER, 
OWNER, and STATE. See Chapter 7 for definitions. (Definitions are 
the same except that there is no SERVICE value permitted for the STATE 
parameter in X.25 because X.25 circuits do not support any of the 
Network Management service functions.) 
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NOTE 

TOPS-10 PSI circuits are not owned by the executor,, 
and the parameters are set at network generation time 
(see the TOPS-10 DECnet and PSI Installation Guide ) ., 
Thus, you cannot change the following arguments with a 
SET/DEFINE command: 

MAXIMUM BLOCK 

MAXIMUM WINDOW 

USAGE PERMANENT 

CHANNEL 

DTE 

TYPE X25 

Only circuits of USAGE permanent are supported. 

Function: 

These commands set volatile and permanent circuit parameters, 
respectively, for the circuit(s) identified by cktid. 

Arguments: 

MAXIMUM DATA bytecnt 

For Permanent Virtual Circuits (PVCs) : the data link 
maximum X.25 block size permitted. For Switched Virtual 
Circuits (SVCs) owned by the executor node: the block size 
that routing is to request from the X.25 protocol handler 
module. Bytecnt is an integer in the range 1-65535. It 
must be less than or equal to the maximum block size allowed 
within the X.25 protocol handler. 

MAXIMUM WINDOW blockcnt 

For PVCs: the data link maximum number of X.25 blocks 
allowed to exist with outstanding acknowledgements. For 
SVCs owned by the executor node: the block count that 
routing is to request from X.25 for the circuit. Blockcnt 
is an integer in the range 1-255. 

USAGE usagtyp 

The value of usagtyp is one of the following: 

INCOMING 

This value is used for SVC incoming calls only and only 
for circuits owned by the executor node. 

OUTGOING 

This value is used for SVC outgoing calls only and only 
for circuits owned by the executor node. 

PERMANENT 

This value is used for all PVCs (circuits permanently 
connected to the same remote station) . 
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BLOCKING blockcntl 

This parameter applies to circuits owned by the executor 
node. The value you enter determines whether or not 
messages are blocked before being sent over the circuit. 
The possible values for blockcntl are: 



ENABLED: Perform blocking 
DISABLED: No blocking 

NUMBER callnum 

This parameter applies to outgoing X.25 circuits owned by 
the executor node. The value you enter in callnum is the 
full remote DTE address used to call out on the circuit. 
The address value must be an integer of one to sixteen 
digits. 

MAXIMUM RECALLS recallcnt 

This parameter applies to outgoing X.25 circuits owned by 
the executor node. The value you enter determines the 
number of automatic call retries. Recallcnt is an integer 
in the range 0-255. If no value is set, there is no 
maximum. 

RECALL TIMER seconds 

This parameter applies to outgoing X.25 circuits owned by 
the executor node. The value you enter determines the 
number of seconds between automatic retries. Seconds is an 
integer in the range 1-65535. If no value is set, there is 
no wa i t . 

CHANNEL chnlnum 

This parameter applies to PVCs only. The value you enter 
for chnlnum is the channel number used in running the X.25 
protocol on the circuit. The channel number is an integer 
in the range 0-4095. 

DTE dteaddr 

This parameter applies to PVCs only. The value you enter is 
the data link X.25 local DTE address to which the circuit 
belongs. DTE address is an integer from one to sixteen 
digits. 

TYPE X25 

For X.25 circuits, you must enter this parameter as TYPE 
X25. If you do not make this entry, the circuit is not 
usable. 
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Entity 



MODULE X25-ACCESS 



Keyword/Argument 

(all network-qualif ieri 
^network-options , 
(network-qualifier 



NOTE 



The use of SET MODULE X25-ACCESS ALL 
there is no permanent data base, 
documentation for the DIGITAL system 
the command. If there is a permanen 
SET command moves all permanent X,2 
data base values to the volatile d 
MODULE X25-ACCESS ALL is never mean 
plural entity KNOWN NETWORKS. 
X25-ACCESS ALL with NODE nodeid 
undefined. 



is meaningless if 

Check the PSI 

that will execute 

t data base, this 

5 ACCESS module 

ata base, DEFINE 

ingful with the 

DEFINE MODULE 

is currently 



Function: 

The SET and DEFINE MODULE X25-ACCESS command sets volatile and 
permanent data base parameters, respectively, needed to connect 
to the X,25 server for one or more networks. 

Arguments: 

network-qualifier 

Network-qualifier indicates the network name to which the 
command applies. If only one network is known, it is the 
default. Network name is the name of the PPSN: TELENET, 
TRANSPAC, or PSS, for example. The possible values for 
network-qualifier are: 

KNOWN NETWORKS 
NETWORK network-name 

network-options 

Network options may be one or more of the following: 

ACCOUNT account 



The value 
be used 
the PSI g 
does not 
access ro 
for more 
account i 
control 
Account i 
TOPS-10. 

NODE node- id 



of the acce 

by the ace 
ateway. Thi 

supply an a 
utines (see 

informatio 
s set, none 

on connec 
s a string o 



ss control account field to 
ess routines in connecting to 
s value is used if the user 
ccount value when calling the 
the TOPS-10 PSI User 's Guide 
n on access routines) . If no 
is included in the access 
t by the access routines, 
f one to 16 characters for 



The identification of the node containing the X.25 
gateway module that gives access to the associated 
PPSN. Node-id is a standard Network Management 
node identification. 
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PASSWORD password 



The value 
be used 
the PSI g 
does not 
routines 
more inf 
password 
control 
Password 
TOPS-10. 



of the 
by the 
ateway. 
supply a 
(see the 
ormation 
is set, 
on CO 
is a str 



access control pa 
access routines 
This value is us 
password when ca 
TOPS-10 PSI Us 
on access rou 
none is included 
nnect by the a 
ing of one to 16 



ssword fi 
in connec 
ed if th 
lling the 
er's Gui 



tines) . 

in the 
ccess ro 

characte 



eld to 

ting to 

e user 

access 

de for 

If no 

access 

utines. 

rs for 



USER user 



The value of 
used by the 
PSI gateway, 
not supply a 
access routin 
for more in 
user is set, 
control on 
is a string o 



the access control user field to be 

access routines in connecting to the 

This value is used if the user does 

user identification when calling the 

es (see the TOPS-10 PSI User's Guide 

formation on access routines) . If no 

none is included in the access 

connect by the access routines. User 

f one to 16 characters for TOPS-10. 

NOTE 



ACCOUNT and 
DECnet-10. 



USER 



are 



not 



used 



m 



Examples: 



NCP>SET MODULE X25-ACCESS NODE DNX25;: NETWORK TELENET 
NCP>SET MODULE X25-ACCESS PASSWORD SECRET 



Remarks: 



Consult the documentation for the operating system of the 
executor node, (Remember that DEFINE will be meaningless if the 
executor node's operating system does not support a permanent 
data base.) 



Command 
(set I 

[DEFINE ( 



Entity 

MODULE X25-PROTOCOL 



Keyword/Argument 

ALL dte-qualif ier 

group-qualifier 
GROUP group-name 

group-options 
CALL TIMER seconds 
CLEAR TIMER seconds 
DEFAULT DATA bytecnt 
DEFAULT WINDOW blockcnt 
MAXIMUM DATA bytecnt 
MAXIMUM CLEARS retrycnt 
MAXIMUM RESETS retrycnt 
MAXIMUM RESTARTS retrycnt 
MAXIMUM WINDOW blockcnt 
NETWORK network-name 
RESET TIMER seconds 
RESTART TIMER seconds 
dte-options dte-qualif ier 



8-6 



NETWORK MANAGEMENT PACKET SWITCHING INTERFACE 

Functions: 

The SET and DEFINE MODULE X25-PROTOCOL commands control the 
parameters necessary to maintain switched and permanent virtual 
circuits through a public packet switching network over the 
assigned X.25 lines of the protocol module. 

Arguments ; 

ALL 

Refer to NOTE for SET/DEFINE MODULE X25-ACCESS. 

ALL dte-qualif ier 

dte-qualif ier indicates the local DTE address to which the 
command applies, dte-qualif ier may be one of: 

KNOWN DTEs 

DTE dte-address 

If only one DTE address is known to the X.25 protocol 
module, that address is the default. If more than one DTE 
address is known, you must give the applicable address, 

ALL group-qualifier 

Group-qualifier indicates the closed user group or bilateral 
closed user group to which the command applies. It may be 
one of the following: 

KNOWN GROUPS 
GROUP group-name 

Group name is an ASCII string of one to sixteen 
characters. It can have any value decided upon by 
the managers of the communicating systems. (See 
the TOPS-10 PS I User's Guide for a description of 
the user groups.) 

ALL has the same interpretation already defined. 

GROUP group-name group-options 

Group-name is defined under the previous argument. 
Group-options is both of the following: 

DTE dte-address 
NUMBER group-number 
TYPE group-type 

DTE-address 

The PPSN DTE address associated with the 
group-name. 

Group-number 

This is the closed user group number (defined 
by the PPSN) . It must be an integer in the 
range 0-9999. 
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Group-type 



If specified, the only value permitted is 
BILATERAL. 



CALL TIMER seconds 



The value you set in seconds determines the elapsed time 
between receiving no response on an outgoing call from the 
DTE and the sending of a clear packet. (The sending of the 
clear packet is transparent to the user.) Seconds is an 
integer in the range 1-255. 

CLEAR TIMER seconds 

The value you enter for seconds determines the elapsed time 
between retransmissions of clear packets. Seconds is an 
integer in the range 1-255. If no value is set, there is no 
retransmission. 

DEFAULT DATA bytecnt 

This is the default block size for SVCs. The value you 
enter must be an integer in the range 1-1021, which is used 
when there is no negotiation for a packet size (see the 
TOPS-10 PS I User' s Guide for more information on the flow 
control parameter negotiation facility) . 

DEFAULT WINDOW blockcnt 

This is the number of unacknowledged transmitted blocks on 
an SVC that can be sent before an acknowledgment is 
received. Once you set this value, it remains in effect 
until changed. The value that you enter must be an integer 
in the range 1-255, which is used when there is no 
negotiation for a window size (see the TOPS-10 PS I User' s 
Guide for more information on the flow control parameter 
negotiation facility) . 

MAXIMUM DATA bytecnt 

The value you enter for this parameter establishes the 
maximum byte count for all X.25 circuits. Bytecnt must be 
an integer in the range 1-1021, which is the maximum value 
you can specify when negotiating for a packet size (see the 
TOPS-10 PS I User' s Guide for more information on the flow 
control parameter negotiation facility) . 

MAXIMUM CLEARS retrycnt 

The value you enter for this parameter determines the 
maximum number of times that the X.25 protocol handler is to 
retry the sending of a clear packet for SVCs. The value 
must be an integer in the range 1-255. If you do not set a 
value, there is no maximum. 

MAXIMUM RESETS retrycnt 

As for preceding parameter, but sets the maximum times for 

retrying the sending of a reset packet. If you do not set 

this value, there is no maximum. Retrycnt is an integer in 
the range 1-255. 
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MAXIMUM RESTARTS retrycnt 

The value you enter for retrycnt determines the maximum 
number of times that the X.25 protocol handler retries the 
sending of a restart. If you do not set this value, there 
is no maximum, Retrycnt is an integer in the range 1-255. 

MAXIMUM WINDOW blockcnt 

The value you enter in blockcnt determines the maximum 
number of unacknowledged transmitted blocks permitted on an 
SVC. The value of blockcnt must be an integer in the range 
1-255, which is the maximum value you can specify when 
negotiating for a window size (see the TOPS-10 PSI User' s 
Guide for more information on the flow control parameter 
negotiation facility) . 

NETWORK network-name 

Previously defined. 

RESET TIMER seconds 

The value you enter for seconds determines the number of 
elapsed seconds between a transmission and a retransmission 
of an unacknowledged reset packet. Seconds must be an 
integer in the range 1-255. If no value is set, there is no 
retransmission. 

RESTART TIMER seconds 

The value you enter for this parameter determines the 
elapsed seconds between transmission and retransmission of 
an outgoing restart packet from the local DTE. Seconds must 
be an integer in the range 1-255. If no value is set, there 
is no retransmission. 

dte-options 

DTE-options, indexed by the local DTE address, include the 
following (not supported by TOPS-10 PSI): 

CHANNELS list 

List is one or more logical channel numbers that 
can be used for outgoing calls or possibly taken 
by incoming calls. If more than one channel 
number is specified, separate by commas. 

COUNTER TIMER seconds 

This is a Network Management timer. The value 
that you enter determines the time interval 
between successive recordings and zeroing of 
protocol module counters. If no value is set, 
there is no automatic logging of counters, 

LINE lineid 

Identification of the line associated with the DTE 
address. It cannot be set or defined by a Network 
Management command. 
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STATE dte-state 

The value you enter must be one of: 

ON - DTE is allowed to operate normally 
OFF - DTE is not operating; all virtual 

circuits terminated immediately 
SHUT - local DTE will not allow new virtual 

circuits; existing virtual circuits 

continue 

Examples: 

NCP>SET EXECUTOR NODE DNX25 

NCP>SET MODULE X23-PR0T0C0L MAXIMUM DATA 128 

NCP>SET MODULE X25-PROTOCOL CHANNELS 10-1 DTE 311030301234 

Command Entity Keyword/Argument 

(set I MODULE X25-SERVER /'ALL destination-qualifier 



1SET f MODULE X25-SERVER ( ALL destination-qualifier \ 
{DEFINE I \ COUNTER TIMER seconds / 

^ ^ < MAXIMUM CIRCUITS count > 

/ destination-options i 
V destination-qualifier/ 



Function: 



The SET/DEFINE MODULE X25-SERVER commands control the parameters 
related to the server module data base. Some parameter values 
entered provide the information needed to map incoming X.25 calls 
to a DECnet process; other parameters are independent of the 
destination name but are needed for more general functions 
related to incoming calls, for example, event recording. 



Arguments : 
ALL 



ALL has the previously defined meaning, related to the 
server module data base. 

destination-qualifier 

Indicates the destination to which the command applies. May 
be one of: 

KNOWN DESTINATIONS - all destinations known to the 
server module DESTINATION destination-name 

destination-name 

The name of a specific destination. Name is an ASCII string 
of from one to sixteen characters. It is the responsibility 
of the system manager to assign destination names for input 
to his node. Because such names must be unique, this 
involves cooperation between managers of communicating 
nodes. 
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COUNTER TIMER seconds 

This counter timer is the Network Management timer that 

determines the elapsed time between the logging of a server 

module logging event. Seconds is an integer in the range 
1-65535. 

MAXIMUM CIRCUITS count 

The value you enter for count indicates the number of 
circuits that the server module can have open at one time. 
Count must be an integer in the range 1-65535. 

destination-options 

You can add new destination names at the initial reference 
to the destination name in an NCP SET command. You can 
remove old names from the data base using the CLEAR command. 
Parameters of an existing destination can be modified. The 
parameters accessed by destination name are described below. 
These parameters are divided into two groups: 

o Parameters that are applied to a field in the incoming 
call packet for the purpose of determining a match. 

o Parameters that define the DECnet characteristics 
necessary to initiate a logical link connect to a DECnet 
object. 



The parameters that are applied to a field of the 
packet are: 



incoming call 



CALL MASK 



hexadecimal string 



This is a string of up to 32 hexadecimal 
characters that is used to determine the 
destination of the incoming call based 
on the content of the user call data 
field of the incoming call packet. This 
value is ANDed byte-by-byte with the 
user call data field of the incoming 
call packet. The resultant string is 
compared with the CALL VALUE. 



CALL VALUE 



GROUP 



hexadecimal string 

This is a string of up to 32 hexadecimal 
characters that is used to determine the 
destination of an incoming call based on 
the content of the user call data field 
of the incoming call packet. This value 
is compared byte-by-byte with the string 
resulting from the CALL MASK operation 
described above to determine the 
destination of an incoming call. 

ascii-string 



This is the closed user group or 
bilateral closed user group name used to 
determine the destination of an incoming 
call based on user group membership. If 
given, only incoming calls with this 
user group name will be routed to this 
destination. 
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NUMBER 



PRIORITY 



SUBADDRESSES 



ascii-string 

This is the full remote DTE address used 
to determine the destination of an 
incoming call based on the calling DTE 
address in the incoming call packet. 
This value must be a string of digits 
and/or asterisks (*) from one to sixteen 
characters . 

decimal number 

This is the priority associated with a 
given entry in the DESTINATION data 
base. The highest priority is 255 and 
the lowest is 0. If an incoming call 
maps to more than one destination, the 
one with the highest priority is chosen. 
If there is more than one match with 
equal priority, the first is chosen, 

range 

This is the range of the local DTE 
subaddresses used to identify the 
destination of an incoming call. If 
given, only those calls with the called 
DTE subaddresses in the specified range 
will be routed to this destination, A 
subaddreas is a decimal number from 
0-99, 

Examples: 

NCP>SET EXECUTOR NODE DNX25 

NCP>SET MODULE X25-SERVER CALL MASK 01 DESTINATION X29SRV 

NCP>SET MODULE X25-SERVER CALL VALUE 01 DESTINATION X29SRE 

NCP>SET MODULE X25-SERVER OBJECT 34 DESTINATION X29SRV 

The following parameters are necessary to initiate a logical link 
connection to a DECnet destination object: 



ACCOUNT 



NODE 



ascii-string 

This is the DECnet access control account string 
used when the Server module connects to the 
destination of an incoming call. The ascii-string 
can contain 1 to 16 characters, 

nodeid 

This is the standard Network Management node name 
used when the Server module connects to the 
destination of an incoming call. This is a 
required parameter. 
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OBJECT 



PASSWORD 



USER 



objectid 

This is the DECnet object identification used when 
the Server module connects to the destination of 
an incoming call. The value objectid can be one 
of the following: 

An ASCII object name or numeric object name 
in quotes, of 1 to 16 characters 

An object number, from 1 to 255 

ascii-string 

This is the DECnet access control password used 
when the Server module connects to the destination 
of an incoming call; must be a string of 1 to 16 
characters. 

ascii-string 

This is the DECnet access control user 

identification to be used when the Server module 

connects to the destination of an incoming call; 
must be a string of 1 to 16 characters. 



Remarks: 



To determine the destination for an incoming call, the 
information in the incoming call packet is compared with the CALL 
MASK, CALL VALUE, GROUP, NUMBER, and SUBADDRESSES parameters in 
each of the DESTINATION entries to see if there is a match. If 
there is a match, the ACCOUNT, NODE, OBJECT, PASSWORD, and USER 
parameters are used to initiate a logical link connect. If there 
is more than one match, the match with the highest PRIORITY is 
taken. If multiple matches have the same PRIORITY, the first 
entry in the data base is used. 

If any of the fields used to identify the DECnet destination of 
an incoming call are missing, then no values are used for the 
missing fields in the identification process. It is the 
responsibility of the receiving node to take care of the 
distribution of messages with missing values in these fields 
(destination-options) . 



A match exists only if all the 
true: 



conditions described below are 



1. The user call data field of the incoming packet, logically 
ANDed byte-by-byte with the CALL MASK, equals the CALL VALUE. 
If the user call data field is longer than the CALL MASK, 
then the strings need only be equal to the end of CALL MASK, 
If the CALL MASK is longer than the user call data field, a 
match can only be obtained if all bytes in the CALL MASK 
beyond the length of the user call data field are zero. 

2, The GROUP parameter equals the closed user group from the 
incoming call packet, or no GROUP parameter is defined. If a 
GROUP parameter is defined and there is no group present in 
the incoming call packet, there is no match. 



8-13 



NETWORK MANAGEMENT PACKET SWITCHING INTERFACE 

3. The NUMBER parameter matches the calling DTE address in the 
incoming call packet. The match is determined by scanning 
both ASCII strings from left to right. The NUMBER parameter 
can be any combination of ASCII characters from to 9 and 
the wildcard character "*'•. A match exists if the following 
is true: 

o There is no NUMBER parameter defined; or 

o Up to the length of the shorter string, each character in 
the NUMBER parameter string contains an "*" or the same 
decimal digit as the DTE address string; and 

a. If the NUMBER parameter string is the shorter of the 
two strings, and the last character in the NUMBER 
parameter string is an asterisk; or 

b. If the NUMBER parameter string is the longer of the 
two strings, the excess characters are all considered 
to be asterisks. 

o If there is no calling DTE address, then a match can 
occur only if the NUMBER parameter string consists of one 
or more asterisks. 

4. The local DTE subaddress from the incoming call packet is in 
the range defined by SUBADDRESSES, or there is no 
SUBADDRESSES range defined. 

For a job to receive incoming calls, it must set itself up as a 
target task. The procedure for doing this is described in the 
TOPS-10 PSI User's Guide . Below are some examples showing the 
relation between the TOPS-10 target task file descriptor and the 
DESTINATION parameters. 

You can specify two types of target tasks. The example below 
shows these and the values of the DESTINATION parameters required 
to connect to the target. 

1. Specify a numbered object in the TOPS-10 program: If the 
user program specifies a target of the form '128', set the 
DESTINATION parameters: 

OBJECT : 128 

NODE : TOPS-10 node number 

2. Specify a named object in the TOPS-10 program: If the user 
program specifies a target of the form 'TASK0', set the 
DESTINATION parameters: 

OBJECT : TASK0 

NODE : TOPS-10 node number 

The parameters USER, PASSWORD, and ACCOUNT are optional. If 
the user program requires those parameters, the system 
manager must set them. 
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Command 



|SET ( 
DEFINE? 



Entity 

(node node id) 
< KNOWN NODES} 
(EXECUTOR ) 



Keyword/ Argument 

See Chapter 7 for all 
applicable parameters 
and values. 



Arguments: 

There is one additional parameter specific to X.25: 

SUBADDRESSES range 

Previously defined (see destination-options for SET MODULE 
X25-SERVER) . The subaddresses parameter distinguishes 
between calls destined for routing and calls destined for 
users. 

All DECnet nodes in which Routing will use X.25 circuits must include 
the SUBADDRESSES parameter. 



Command 
(set ) 

IDEFINEl 



Entity 
LINE linetd 



Keyword/Argument 

Specific to LAPB (X.25 lines): 

(holdback TIMER seconds 

j MAXIMUM BLOCK byte-count 

) MAXIMUM RETRANSMITS block-count | 

f MAXIMUM WINDOW block-count 

Common to DDCMP and 
LAPB(X.25) lines: 

CLOCK clock-mode 
CONTROLLER controller-mode 
COUNTER TIMER seconds 
DEVICE deviceid 
DUPLEX duplex-mode 
PROTOCOL protocol-name 
RETRANSMIT TIMER milliseconds 
SERVICE service-control 
STATE line-state 



Arguments: 



With the exception of PROTOCOL, keywords and arguments common to 
DDCMP and LAPB lines are adequately defined in the previous 
chapter. For PROTOCOL, the protocol name for lines using X.25 
protocol must be LAPB. 

HOLDBACK TIMER seconds 

The value you enter for seconds determines the length of 
time an acknowledgement is held back to wait for a data 
message with which it can be included. If you do not 
specify a value, ' there is no wait. (This argument is not 
implemented for TOPS-10 PSI.) 

MAXIMUM BLOCK byte-count 

The value you enter determines the data link maximum byte 
count of the block size on the line. Byte count must be an 
integer in the range 1-65535. 



8-15 



NETWORK MANAGEMENT PACKET SWITCHING INTERFACE 



MAXIMUM RETRANSMITS block-count 

The value you enter in block-count determines the data link 
maximum number of retransmissions of a block on the line. 
Block-count must be an integer in the range 1-255. If you 
do not set a value, there is no maximum. 

MAXIMUM WINDOW block-count 

The value you enter for block-count determines the maximum 
number of unacknowledged transmitted blocks permitted on a 
line. Block-count must be an integer in the range 1-255. 

Example: 

NCP>TELL DNX25 SET LINE KDP-0-0 MAXIMUM RETRANSMITS 20 



Command 

(sHOwl 
|LISTj 



Entity 

MODULE module-name 



ACTIVE MODULES 
KNOWN MODULES 



Keyword/Argument 

Specific to named 
module; see "Arguments:" 
for keywords and values 
of each module name. 

CHARACTERISTICS 
COUNTERS 
STATUS 
SUMMARY 



Function: 



The SHOW command displays information from the volatile data 
base; the LIST command displays information from a permanent data 
base. 



Arguments: 



Arguments for the entities ACTIVE MODULES and KNOWN MODULES are 
defined in Section 7,7. Arguments for named modules are: 



Entity 

MODULE X25-ACCESS 



Keyword/Argument 

characteristics) [KNOWN NETWORKS] 
COUNTERS ( [NETWORKS network-name] 
STATUS 
SUMMARY 



MODULE X25-PROTOCOL (CHARACTERISTICS) [DTE dte-address] 

COUNTERS ( [KNOWN DTES] 
STATUS ( [GROUP group-name] 
SUMMARY I [KNOWN GROUPS] 

MODULE X25-SERVER (CHARACTERISTICS) [KNOWN DESTINATIONS] 

COUNTERS ( [DESTINATION destination-name] 
, STATUS 
SUMMARY 

All X.25-specif ic parameters for named modules are previously 
defined in this chapter. 
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Examples: 



NCP>SHOW MODULE X25-ACCESS CHARACTERISTICS KNOWN NETWORKS<RET> 

NCP> 

15:01:11 NCP 

Request # 3; Show Module Characteristics Completed 

Module = X25-ACCESS 

Network = TELENET 
Node = 7.129 (MRX25) 
Password = X25-GATE 

NCP>SET EXECTOR NODE MRX25<RET> 

NCP> 

15:01:24 NCP 

Set Executor Complete 
NCP>SHOW MODULE X25-PROTOCOL CHARACTERISTICS KNONW DTES<RET> 
15:05:24 NCP 

Request # 6 Accepted 
NCP> 

15:05:25 NCP 

Request # 6; Show Module Characteristics Completed 
Module = X25-PROTOCOL 

DTE = 311030300170 

Line = KDP-0-0 

Channels = 20-1 

Maximum Channels = 20 
NCP>SHOW MODULE X25-PROTOCOL CHARACTERISTICS<RET> 
NCP> 
15:05:35 NCP 

Request # 7 Accepted 
NCP> 

15:05:35 NCP 

Request # 7; Show Module Characteristics Completed 
Module = X25-PROTOCOL 

Network = TELENET 

Default Data = 128 

Default Window = 2 

Maximum Data = 256 

Maximum Window = 2 

Maximum Clears = 6 

Maximum Resets = 6 

Maximum Restarts = 6 

Call Timer = 180 

Clear Timer = 180 

Reset Timer = 180 

Restart Timer = 180 
NCP>SHOW MODULE X25-PROTOCOL COUNTEERS KNOWN DTES<RET> 
NCP> 
15:14:17 NCP 

Request # 24 Accepted 
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NCP> 

15:14:18 NCP 

Request # 24; Show Module Characteristics Completed 

Module = X25-PROTOCOL 

DTE = 311061700084 

Seconds Since Last Zeroed 

25783 Bytes Received 

872951 Bytes Sent 

17029 Data Blocks Received 

28397 Data Blocks Sent 

69 Calls Received 

23 Calls Sent 

Fast Selects Received 

Fast Selects Sent 

12 Maximum Switched Circuits Active 

4 Maximum Channels Active 

Received Call Resource Errors 

8 Locally Initiated Resets 

2 Network Initiated Resets 

Remotely Initiated Resets 

1 Restarts 

NCP>SHOW MODULE X25-SERVER CHARACTERISTICS KNOWN DESTINATION<RET> 

NCP> 

15:16:12 NCP 

Request # 25 Accepted 
NCP> 

15:16:15 NCP 

Request # 25; Show Module Characteristics Completed 
Module = X25-SERVER 

Destination = X29 
Node = 120 
Object = 34 
Priority = 5 
Call Mask = FF 
Call Value = 01 

Destination = KL2137 
Node = KL2137 
Object = 34 
Priority = 1 
Call Mask = 01 
Call Value = 01 

Destination = X25 

Node = 120 

Object = (X25TST) 

Priority = 

Subaddresses = 1 
NCP>SHOW MODULE X25-SERVER COUNTERS<RET> 
NCP> 
15:16:37 NCP 

Request # 26 Accepted 
NCP> 

15:16:37 NCP 

Request # 26; Show Module Counters Completed 
Module = X25-SERVER 

Seconds Since Last Zeroed 

12 Maximum Circuits Active 

Incoming Calls Rejected, No Resources 

Logical Links Rejected, No Resources 
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Command Entity Keyword/Argument 

ZERO (module X25-SERVER [COUNTERS] 

) KNOWN MODULES 

VmODULE X25-PROTOCOL COUNTERS [KNOWN DTES] 

I [DTE dte-address] 

Function: 

The zero command used with the module entity generates a counters 
zeroed event that causes counters to be logged and then zeroed. 
The counters zeroed are those the executor node supports for the 
entity that you specified, and possibly qualified, in the 
command. 

Arguments: 

All arguments previously defined in this chapter. 

Remarks: 

The command ZERO MODULE X25-PROTOCOL COUNTERS can be used only if 
there is no more than one DTE address on the executor node. If 
there is more than one DTE address, use the qualifier DTE 
dte-address, that is, ZERO MODULE X25-PROTOCOL COUNTERS DTE 
dte-address. You can also use the command in the form ZERO 
MODULE X25-PROTOCOL COUNTERS KNOWN DTES. 

Examples : 

NCP>SET EXECUTOR NODE MRX25 

NCP>ZERO MODULE X25-SERVER COUNTERS 

NCP>ZERO MODULE X25-PROTOCOL COUNTER KNOW DTES 

Command Entity Keyword/Argument 

(clear) (circuit cktid ) ( MAXIMUM RECALLs) 
(PURGE j (KNOWN CIRCUITS? (RECALL TIMER j 

Function: 

All CLEAR and PURGE commands clear parameters from the volatile 
and permanent data bases respectively. 

Arguments: 

No arguments specific to X.25. See Section 7.6 
Example: 

NCP>CLEAR CIRCUIT KDP-0-1 RECALL TIMER 

JclearI (line lineidl (all ) 

(PURGE ( (KNOWN LINES ( ) COUNTER TIMER ( 

^ ^ ^ i HOLDBACK TIMER ( 

"maximum RETRANSMITS! 



It 
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Arguments: 

ALL and COUNTER TIMER: see Section 7.6. HOLDBACK TIMER and 
MAXIMUM RETRANSMITS are X. 25-specif ic and previously defined 
under SET LINE lineid in this chapter. 

Example: 

NCP>TELL MRX25 CLEAR LINE KDP-0-0 MAXIMUM RETRANSMITS 

(clear) MODULE X25-ACCESS ( ALL network-qualifier) 
I PURGE ( I network-options > 

^ ^ I network qualifier ) 

Arguments: 

network-options 

May be one or more of: ACCOUNT, PASSWORD, USER. 

All arguments are previously defined. See SET/DEFINE for MODULE 
X25-ACCESS. 

Example: 

NCP>CLEAR MODULE X25-ACCESS PASSWORD NETWORK TELENET 

(clear) MODULE X25-PROTOCOL / ALL dte-qualif ier 
I PURGE i I group-qualifier 

^ ' ■ GROUP group-name 

group-options 

CALL TIMER 

CLEAR TIMER 

MAXIMUM CLEARS 

MAXIMUM RESETS 

MAXIMUM RESTARTS 

RESET TIMER 

dte-options dte-qualif ier 

Arguments: 

All arguments previously defined in this chapter. See SET/DEFINE 
for MODULE X25-PROTOCOL. 

Example: 

NCP>TELL MRX25 CLEAR MODULE X25-PROTOCOL MAXIMUM CLEARS 

(clear) module X25-SERVER (alL destination-qualifier 
I PURGE ( ) COUNTER TIMER seconds 



(destination-options 
destination-qual 



ifier 



Arguments; 



Previously defined in this chapter. See SET/DEFINE MODULE 
X25-SERVER. 

Example: 

NCP>TELL MRX25 CLEAR MODULE X25-SERVER SUBADDR DEST KL2137 
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APPENDIX A 
DECnet PARAMETER SUMMARY 



A-1 



DECnet PARAMETER SUMMARY 



Table A-1: Node Parameters 



Digital Network Architecture 


DECnet- 10V4.0 Implementation 


Param. 














Type No. 


NCP Keywords 


Applicability 


Restrictions 


TOPS- 10 


MCE 


Restrictions 





STATE 

ON(Executor) 

1 OFF(Executor) 

2 SHUT(Executor) 

3 RESTRICTED 
(Executor) 

4 REACHABLE 
(Remote) 

5 UNREACHABLE 
(Remote) 


All nodes except 
Loop nodes 




X 


X 


Can not be set 
Can be displayed 


10 


PHYSICAL ADDRESS 


Ethernet loop 
nodes only 


Display only 


X 






100 


IDENTIFICATION 


EXECUTOR only 




X 


X 




101 


MANAGEMENT VERSION 
Version Number 
ECO Number 
User ECO Number 


EXECUTOR only 


Display only 








110 


SERVICE CIRCUIT 


Adjacent only 




X 


X 




111 


SERVICE PASSWORD 


Adjacent only 




X 


X 




112 


SERVICE DEVICE 


Adjacent only 




X 


X 




113 


CPU 

PDP-8 

1 PDP-11 

2 DECSYSTEM-1020 

3 VAX 


Adjacent only 




X 
X 
X 
X 

X 


X 
X 




114 


HARDWARE ADDRESS 


Adjacent only 




X 




Can not be set 


115 


SERVICE NODE VERSION 

phase III 

1 phase IV 


Ac^acent only 




X 




Can be displayed 


120 


LOAD FILE 


Adjacent only 




X 


X 




121 


SECONDARY LOADER 


Adjacent only 




X 


X 




122 


TERTIARY LOADER 


Adjacent only 




X 


X 




123 


DIAGNOSTIC FILE 


Adjacent only 




X' 






125 


SOFTWARE TYPE 

SECONDARY LOADER 

1 TERTIARY LOADER 

2 SYSTEM 


Adjacent only 




X 


X 




126 


SOFTWARE IDENTIFICATION 


Adjacent only 










130 


DUMP FILE 


Adjacent only 




X 


X 




131 


SECONDARY DUMPER 


Adjacent only 




X 


X 




135 


DUMP ADDRESS 


Adjacent only 










136 


DUMP COUNT 


A4jacent only 










140 


HOST 
Node address 
Node name (if any) 


At^jacent and 
EXECUTOR only 


Display only 


X 


X 




141 


HOST 


Adjacent and 
set only 
EXECUTOR only 




X 


X 


Can be set, displayed 
as parameter #140 


150 


LOOP COUNT 


EXECUTOR only 


Used with LOOP 
command only 


X 


X 


Used with LOOP 
command only 


151 


LOOP LENGTH 


EXECUTOR only 


Used with LOOP 
command only 


X 


X 


Used with LOOP 
command only 


152 


LOOP WITH 

zeroes 

1 ones 

2 mixed 


EXECUTOR only 


Used with LOOP 
command only 


X 


X 


Used with LOOP 
command only 


153 


LOOP ASSISTANT 
PHYSICAL ADDRESS 


EXECUTOR only 


Used with LOOP 
command only 


X 




Not implemented 


154 


LOOP HELP 

transmit 

1 receive 

2 full 


EXECUTOR only 


Used with LOOP 
command only 


X 
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DECnet PARAMETER SUMMARY 



Table A-1: Node Parameters (Cont.) 





Digital Network Architecture 


DECnet-10V4.0 Implementation 


Param. 














Type No. 


NCP Keywords 


Applicability 


Restrictions 


TOPS-10 


MOB 


Restrictions 


155 


LOOP NODE 


EXECUTOR only 


Used with LOOP 
command only 


X 


X 




156 


LOOP ASSISTANT NODE 


EXECUTOR only 


Used with LOOP 
command only 


X 






160 


COUNTER TIMER 


All nodes except 
loop nodes 




X 


X 




500 


NAME 


All nodes except 
loop nodes 


Special format 


X 


X 


Can not be set for 
EXECUTOR, can be 
set for other nodes. 
Will be displayed 
in node-id 


501 


CIRCUIT 


Loop nodes and 
nodes by name 
only 




X 


X 




502 


ADDRESS 


EXECUTOR only 


Special format 


X 


X 


Can not be set 
Displayed in 
node-id 


510 


INCOMING TIMER 


EXECUTOR only 




X 


X 




511 


OUTGOING TIMER 


EXECUTOR only 




X 


X 




600 


ACTIVE LINKS 


All nodes except 
loop nodes 


Display only 


X 


X 




601 


DELAY 


All nodes except 
EXECUTOR and 
loop 


Display only 


X 


X 




700 


NSP VERSION 
Version Number 
ECO Number 
User ECO Number 


EXECUTOR only 


Display only 


X 


X 




710 


MAXIMUM LINKS 


EXECUTOR only 




X 


X 


Can not be set 
Can be displayed 


720 


DELAY FACTOR 


EXECUTOR only 




X 


X 




721 


DELAY WEIGHT 


EXECUTOR only 




X 


X 




722 


INACTIVITY TIMER 


EXECUTOR only 




X 


X 




723 


RETRANSMIT FACTOR 


EXECUTOR only 




X 


X 




810 


TYPE 

ROUTING III 

1 NONROUTING III 

3 AREA 

4 ROUTING IV 

5 NONROUTING IV 


Adjacent only 


Display only 


X 


X 




820 


COST 


All nodes except 
EXECUTOR and 
loop 


Display only 


X 


X 


Can not be set in 

MCB 

Can be displayed 


821 


HOPS 


All nodes except 
EXECUTOR and 
loop 


Display only 


X 


X 


Can not be set in 

MCB 

Can be displayed 


822 


CIRCUIT 


All nodes except 
EXECUTOR and 
loop 


Display only 


X 


X 


Can not be set in 

MCB 

Can be displayed 


830 


NEXT NODE 
Node address 
Node name (if any) 


All nodes except 
EXECUTOR and 
loop 


Display only 


X 


X 




900 


ROUTING VERSION 
Version Number 
ECO Number 
User ECO Number 


EXECUTOR only 


Display only 


X 


X 




901 


TYPE 

ROUTING III 

1 NONROUTING III 

3 AREA 

4 ROUTING IV 

5 NONROUTING IV 


EXECUTOR only 




X 


X 


Can not be set 
Can be displayed 


910 


ROUTING TIMER 


EXECUTOR only 




X 


X 




911 


SUBADDRESSES 
Range beginning 
Range end 


EXECUTOR only 
X.25 only 






X 




912 


BROADCAST ROUTING 
TIMER 


EXECUTOR only 




X 
X 






920 


MAXIMUM ADDRESS 


EXECUTOR only 




X 


X 




921 


MAXIMUM CIRCUITS 


EXECUTOR only 




X 


X 


Can not be set 
in MCB 
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DECnet PARAMETER SUMMARY 



Table A-1; Mode Parameters (Cont.) 



Digital Networli Architecture 


DECnet-10V4.0 Implementation 


Param. 














Type No. 


NCP Keywords 


Applicability 


Restrictions 


TOPS- 10 


MCB 


Restrictions 


922 


MAXIMUM COST 


EXECUTOR only 




X 


X 




923 


MAXIMUM HOPS 


EXECUTOR only 




X 


X 




924 


MAXIMUM VISITS 


EXECUTOR only 




X 


X 




925 


MAXIMUM AREA 


EXECUTOR only 








Not implemented 


926 


MAXIMUM BROADCAST 
NONROUTERS 


EXECUTOR only 




X 
X 






927 


MAXIMUM BROADCAST 
ROUTERS 


EXECUTOR only 




X 
X 






928 


AREA MAXIMUM COST 


EXECUTOR only 




X 






929 


AREA MAXIMUM HOPS 


EXECUTOR only 




X 






930 


MAXIMUM BUFFERS 


EXECUTOR only 




X 


X 


Can not be set in 

MCB 

Can be displayed 


931 


BUFFER SIZE 


EXECUTOR only 




X 


X 


Can not be set in 

MCB 

Can be displayed 


932 


SEGMENT BUFFER SIZE 


EXECUTOR only 




X 




Can not be set 
Can be displayed 



Table A-2: DECnet-10 Specific Node Parameters 



Param. 
Type No. 


NCP Keywords 


Applicability 


TOPS-10 


MCB 


2511 
2512 


CONSOLE SECONDARY 
LOADER 

CONSOLE LOAD 
FILE 


Adjacent 
Ethernet 
Pommunications 
Servers only 

Adjacent 
Ethernet 
Communications 
Servers only 


X 
X 
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DECnet PARAMETER SUMMARY 



Table A-3: Line Parameters 



Digital Network Architecture 


DECnet-lbV4.0 Implementation 


Param. 














Type No. 


NOP Keywords 


Applicability 


Restrictions 


TOPS-10 


MCB 


Restrictions 





STATE 
OON 
lOFF 

2 SERVICE 

3 CLEARED 


All lines 




X 


X 


Code 2 in MCB 
display only 


1 


Substate (not a keyword) 

STARTING 

1 REFLECTING 

2 LOOPING 

3 LOADING 

4 DUMPING 

5 TRIGGERING 

6 AUTOSERVICE 

7 AUTOLOADING 

8 AUTODUMPING 

9 AUTOTRIGGERING 

10 SYNCHRONIZING 

11 FAILED 


All lines 


Display only 


X 


X 




100 


SERVICE 

ENABLED 

1 DISABLED 


DDCMP lines 
only 






X 




110 


COUNTER TIMER 


All circuits 




X 


X 




1100 


DEVICE 












1105 


RECEIVE BUFFERS 






X 


X 


Can not be set 


1110 


CONTROLLER 

NORMAL 

1 LOOPBACK 






X 


X 


Can be displayed 
Can not be set 
Can be displayed 


1111 


DUPLEX 








X 




1112 


PROTOCOL 

DDCMP POINT 

1 DDCMP CONTROL 

2 DDCMP TRIBUTARY 

3 (reserved) 

4 DDCMP DMC 
5LAPB 

6 ETHERNET 

7 CI 

8 QP2 (DTE20) 


DDCMP lines 






X 


Can not be set 
Can be displayed 


1113 


CLOCK 


All lines 






X 


Can not be set 


1120 


EXTERNAL 

1 INTERNAL 
SERVICE TIMER 


ALL DDCMP 
lines 






X 


displayed for KDP 
lines only. * (state off) 
Parameter value 
must be in 


1121 


RETRANSMIT TIMER 


All lines 






X 


multiples of seconds 
Not for DTE 


1122 


HOLD BACK TIMER 












1130 


MAXIMUM BLOCK 












1131 


MAXIMUM RETRANSMITS 












1132 


MAXIMUM WINDOW 


X.25 only 






X 


Can not be set 


1150 


SCHEDULING TIMER 










Can be displayed 


1151 


DEAD TIMER 












1152 


DELAY TIMER 












1153 


STREAM TIMER 












1160 


HARDWARE ADDRESS 


Ethernet lines 
only 


Display only 


X 
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DECnet PARAMETER SUMMARY 



Table A-4: DECnet-'10 Specific Line Parameters 



Param. 
Type No. 


NOP 

Keywords 


TOPS- 10 


MCB 


Restrictions 


2500 


RECEIVE 
BUFFER SIZE 


X 




CI and NI only 
Can be displayed 


2650 


CONTROLLER 
REGISTER 




X 


DTE only 

Can be displayed 


2651 


UNIT REGISTER 




X 


All line devices 
except KDP 


2655 


INTERRUPT 
VECTOR 




X 


All line devices 
except KDP 
Can be displayed 


2660 


INTERRUPT 
PRIORITY 




X 


All line devices 
except KDP 
Can be displayed 


2670 


PAUSE TIMER 




X 


DTE only 

Can be displayed 



None of the DECnet-10 specific line parameters can be set by the user. 



Table A-5: Circuit Parameters 



Digital Network Architecture 


DECnet-10V4.0 Implementation 


Param. 














Type No. 


NCP Keywords 


Applicability 


Restrictions 


TOPS-10 


MCB 


Restrictions 





STATE 
OON 
lOFF 

2 SERVICE 

3 CLEARED 


All circuits 


Display only 


X 


X 


Code 2 in MCB 


1 


substate (not a keyword) 

STARTING 

1 REFLECTING 

2 LOOPING 

3 LOADING 

4 DUMPING 

5 TRIGGERING 

6 AUTOSERVICE 

7 AUTOLOADING 

8 AUTODUMPING 

9 AUTOTRIGGERING 

10 SYNCHRONIZING 

11 FAILED 


All circuits 


Display only 


X 


X 


Code 3 not 
implemented 


100 


SERVICE 

ENABLED 

1 DISABLED 


All circuits used 
for service 




X 


X 




110 


COUNTER TIMER 


All circuits 




X 


X 




120 


SERVICE PHYSICAL 
ADDRESS 


Ethernet 
Circuits only 


Display only 


X 






121 


SERVICE SUBSTATE 

STARTING 

1 REFLECTING 

2 LOOPING 

3 LOADING 

4 DUMPING 

5 TRIGGERING 

6 AUTOSERVICE 

7 AUTOLOADING 

8 AUTODUMPING 

9 AUTOTRIGGERING 

10 SYNCHRONIZING 

11 FAILED 




Display only 








200 


CONNECTED NODE 
Node address 
Node name (if any) 


X.25 


Display only 








201 


CONNECTED OBJECT 
Object number 
Object name 




Display only 









A-6 



DECnet PARAMETER SUMMARY 



Table A-5: Circuit Parameters (Cont.) 



Digital Network Arcliitecture 


DECnet-10V4.0 Implementation 


Par am. 














Type No. 


NCP Keywords 


Applicability 


Restrictions 


TOPS- 10 


MOB 


Restrictions 


400 


LOOPBACK NAME 




Display only 


X 






800 


ADJACENT NODE 
Node address 
Node name (if any) 




Display only 


X 






801 


DESIGNATED ROUTER 
Node address 
Node name (if any) 




Display only 


X 






810 


BLOCK SIZE 




Display only 








811 


ORIGINATING 
QUEUE LIMIT 












900 


COST 






X 


X 




901 


MAXIMUM ROUTERS 


Ethernet node 
circuits only 




X 






902 


ROUTER PRIORITY 


Ethernet node 
circuits only 




X 






906 


HELLO TIMER 






X 






907 


LISTEN TIMER 


EXECUTOR node 
circuits only 


Display only 




X 




910 


BLOCKING 

ENABLED 

1 DISABLED 


X.25 only 










920 


MAXIMUM RECALLS 


X.25 only 










921 


RECALL TIMER 


X.25 only 










930 


NUMBER 


X.25 only 










1000 


USER 
Entity type 
Entity name (if entity 

is not node) 
Node address (if entity 

is not node) 
Node name (if entity 

is not node) 


EXECUTOR node 
circuits only 
Node circuits only 


Display only 




X 




1010 


POLLING STATE 

AUTOMATIC 

1 ACTIVE 

2 INACTIVE 

3 DYING 

4 DEAD 










Not implemented 


1011 


Polling substate 

ACTIVE 

1 INACTIVE 

2 DYING 

3 DEAD 










Not implemented 


1100 


OWNER 












1110 


LINE 












1111 


USAGE 

PERMANENT 

1 INCOMING 

2 OUTGOING 


X.25 only 








Only USAGE 
PERMANENT 
is supported. 
Can not be set 
Can be displayed 


1112 


TYPE 

DDCMP POINT 

1 DDCMP CONTROL 

2 DDCMP TRIBUTARY 
3X25 

4 DDCMP DMC 

5 

6 ETHERNET 




Display only 






















7 01 














8 QP2 (DTE20) 














9 BISYNC 












1120 


DTE 


X.25 only 






X 


Can not be set 
Can be displayed 


1121 


CHANNEL 


X.25 only 






X 


Can not be set 
Can be displayed 


1122 


MAXIMUM DATA 


X.25 only 






X 


Can not be set 
Can be displayed 


1123 


MAXIMUM WINDOW 


X.25 only 






X 


Can not be set 
Can be displayed 


1140 


TRIBUTARY 










Not implemented 


1141 


BABBLE TIMER 










Not implemented 


1142 


TRANSMIT TIMER 










Not implemented 


1145 


MAXIMUM BUFFERS 
1-254 Number of buffers 
255 UNLIMITED 










Not implemented 
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DECnet PARAMETER SUMMARY 



Table A-5: Circuit Parameters (Cont.) 



Digital Network Architecture 


DECnet-10V4.0 Implementation 


Par am. 














Type No. 


NCP Keywords 


Applicability 


Restrictions 


TOPS- 10 


MCB 


Restrictions 


1146 


MAXIMUM TRANSMITS 










Not implemented 


1150 


ACTIVE BASE 










Not implemented 


1151 


ACTIVE INCREMENT 










Not implemented 


1152 


INACTIVE BASE 










Not implemented 


1153 


INACTIVE INCREMENT 










Not implemented 


1154 


INACTIVE THRESHOLD 










Not implemented 


1155 


DYING BASE 










Not implemented 


1156 


DYING INCREMENT 










Not implemented 


1157 


DYING THRESHOLD 










Not implemented 


1158 


DEAD THRESHOLD 










Not implemented 



Table A~6: Logging Parameters 



Digital Network Architecture 


DECnet-10V4.0 Implementation 1 


Param. 














Type No. 


NCP Keywords 


Applicability 


Restrictions 


TOPS-10 


MCB 


Restrictions 





STATE 
OON 
lOFF 
2 HOLD 


The EXECUTOR 
node's logging 
state for the 
specified logging 
sink. 




X 




Implemented for 
logging file only. 


100 


NAME 


The specific sink 
specified by the 
EXECUTOR as 
the event-receiver: 
device name, file 
name, or process 
identification for 
the sink types 
CONSOLE, FILE, 
and MONITOR. 




X 




For MONITOR 
only 


200 


SINK NODE 
Node address 
Node name (if any) 


The node that 
the EXECUTOR 
specifies as the 
event-receiver 










201 


EVENTS 
Entity type 
-1 no entity 

node 

nine 

3 circuit 

4 module 

5 area 
Node address 

(if entity type is node) 
Node name 

(if entity type is node) 
Identification 

(lineid or cktid as 

indicated by entity type) 
Entity class 

single class 

2 all events for class 

3 KNOWN EVENTS 
Event class 

(if entity class is or 2) 
Event mask 
(if entity class is 0) 


The events at the 
source node to 
be recorded at the 
SINK NODE. 
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DECnet PARAMETER SUMMARY 



Table A-7: Event Parameters 



Network Management Layer Parameters - Class 


Session Control Layer Event Parameters - Ciasa 2 (Cent.) 


Type 


Keywords 


Type 


Keywords 





SERVICE 


2 


NEW STATE 




OLOAD 




OON 




IDUMP 




1 OFF 


1 


STATUS 




2 SHUT 




Return code 




3 RESTRICTED 




REQUESTED 


3 


SOURCE NODE 




>0 SUCCESSFUL 




Node address 




<0 FAILED 




Node name (if any) 




Error detail (if error) 


4 


SOURCE PROCESS 




Error message (optional) 




Object type 


2 


OPERATION 




Group code 




INITIATED 




User code 




1 TERMINATED 




Process name 


3 


REASON 


5 


DESTINATION PROCESS 




Receive timeout 




(same as for SOURCE PROCESS) 




1 Receive error 


6 


USER 




2 Line state change by higher level 


7 


PASSWORD 




3 Unrecognized request 




(0 means password set; 




4 Line open error 




no parameter means not set) 


4 


Qualifier 

Parameter type 

Id string 
NODE 

Node address 


8 


ACCOUNT 


5 


Network Services Layer Event Parameters - Class 3 


Type 


Keywords 




Node name (if any) 





MESSAGE 


6 


DTE 




Message flags 


7 


Filespec 




Destination link address 


8 


SOFTWARE TYPE 




Source link address 




SECONDARY LOADER 




Data 




1 TERTIARY LOADER 


1 


CURRENT FLOW CONTROL REQUEST COUNT 




3 SYSTEM 


2 


No flow control 

1 Segment flow control 

2 Message flow control 
SOURCE NODE 


Session Control Layer Event Parameters - Class 2 


Type 


Keywords 








Node address 





REASON 

Operator command 

1 Normal operation 




Node name (if any) 


1 


OLD STATE 
OON 
lOFF 

2 SHUT 

3 RESTRICTED 
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DECnet PARAMETER SUMMARY 



Table A-7: Event Parameters (Cont.) 



Transport Layer Event Parameters - Class 4 


Data Link Layer Event Parameters - Class 5 


Type 


Keywords 


Type 


Keywords 





PACKET HEADER (non-Ethernet) 





OLD STATE 




Message flags 




HALTED 




Destination node address (not for control 




1 ISTRT 




packet) 




2 ASTRT 




Source node address 




3 RUNNING 




Visit count (not for control packet) 




4 MAINTENANCE 





PACKET (Ethernet) 


1 


NEW STATE 




Message flags 




HALTED 




Destination area 




1 ISTRT 




Destination subarea 




2 ASTRT 




Destination Ethernet address 




3 RUNNING 




Source area 




4 MAINTENANCE 




Source subarea 


2 


HEADER 




Source Ethernet address 


3 


SELECTED TRIBUTARY 




Next area router 


4 


PREVIOUS TRIBUTARY 




Visit count 


5 


TRIBUTARY STATUS 




Service class 




Streaming 




Protocol type 




1 Continued send after timeout 


1 


PACKET BEGINNING 




2 Continued send after deselect 


2 


HIGHEST ADDRESS 




3 Ended Streaming 


3 


NODE 


6 


RECEIVED TRIBUTARY 




Node address 


7 


BLOCK LENGTH 




Node name (if any) 


8 


BUFFER LENGTH 


4 


EXPECTED NODE 


9 


DTE 




Node address 


10 


REASON 




Node name (if any) 




Operator command 


5 


REASON 




1 Normal operation 




Circuit synchronization lost 


11 


OLD STATE (for event 5.12) 




1 Data errors 




OON 




2 Unexpected packet type 




1 OFF 




3 Routing update checksum error 




2 SHUT 




4 AcUacent node address change 


12 


NEW STATE (for event 5.12) 




5 Verification receive timeout 




OON 




6 Version skew 




lOFF 




7 Ac^jacent node address out of range 




2 SHUT 




8 Adjacent node block size too small 


13 


PARAMETER TYPE 




9 Invalid verification seed value 


14 


CAUSE 




10 Adjacent node listener receive 


15 


DIAGNOSTIC 






16 


FAILURE REASON 




11 A<ijacent node listener received 




Excessive colli9ions 




invalid data 




1 Carrier check failed 




12 Call failed 




2 (obsolete) 




13 Verification password required from 




3 Short circuit 




Phase III node 




4 Open circuit 




14 Dropped by adjacent node 




5 Frame too long 


6 


RECEIVED VERSION 




6 Remote failure to defer 




Version number 




7 Block check error 




ECO number 




8 Framing error 




User ECO number 




9 Data overrun 


7 


STATUS 




10 System buffer unavailable 




REACHABLE 




1 1 User buffer unavailable 




1 UNREACHABLE 




12 Unrecognized frame destination 


8 


ADJACENT NODE 


17 


DISTANCE 




Node address 


18 


ETHERNET HEADER 




Node name (if any) 




Destination address 
Source address 
Protocol type 






19 


HARDWARE ADDRESS 


Physical Line Layer Parameters - Class 6 


Type 


Keywords 









DEVICE REGISTER 






1 


NEW STATE 
OOFF 
1 ON 
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DECnet PARAMETER SUMMARY 



Table A-8 : Module X25-ACCESS Parameters 



Digital Network Architecture 


DECnet-10V4.0 Implementation 


Parameter 
Number 


NCP Keywords 


Applicability 


Restrictions 


TOPS-10 


MCB 


Restrictions 


320 


NODE 
Node address 
Node name (if any) 


Qualified parameter 




X 






330 


USER 


Qualified parameter 




X 




Unused in TOPS-10 


331 


PASSWORD (to set) 
(0 means password 
set; no parameter 
means not set) 


Qualified parameter 


Set only 


X 




Can be displayed 
in TOPS-10 


331 


PASSWORD (to read) 
(0 means password 
set; no parameter 
means not set) 


Qualified parameter 


Display only 








332 


ACCOUNT 


Qualified parameter 




X 




Unused in TOPS-10 


1110 


NETWORK 


Qualifying parameter 




X 







Table A-9: Module X25-PROTOCOL Parameters 



Digital Network Architecture 


DECnet- 10V4.0 Implementation | 


Parameter 
Number 


NCP Keywords 


Applicability 


Restrictions 


TOPS-10 


MCB 


Restrictions 





STATE 
OON 
lOFF 
2 SHUT 


Qualified by DTE 






X 




1 


Substate (not a keyword) 
Running 
ISync 
2 Unsync 




Display only 








100 


COUNTER TIMER 


Qualified by DTE 






X 


Non-qualified 
parameter in MCB 


1000 


ACTIVE CHANNELS 


Qualified by DTE 


Display only 




X 




1010 


ACTIVE SWITCHED 


Qualified by DTE 


Display only 




X 




1100 


DTE 


Qualifying parameter 






X 


Display only in MCB 


1101 


GROUP 


Qualifying parameter 






X 




1110 


NETWORK 








X 


Display only in MCB 


1120 


LINE 


Qualified by DTE 






X 


Display only in MCB 


1130 


CHANNELS 
range beginning 
range end (none if 
same as beginning) 


Qualified by DTE 






X 


* (state ofi) 


1131 


MAXIMUM CHANNELS 


Qualified by DTE 


Display only 




X 




1132 


MAXIMUM CIRCUITS 


Qualified by DTE 










1140 


DEFAULT DATA 








X 




1141 


DEFAULT WINDOW 








X 




1150 


MAXIMUM DATA 








X 




1151 


MAXIMUM WINDOW 








X 




1152 


MAXIMUM CLEARS 








X 




1153 


MAXIMUM RESETS 








X 




1154 


MAXIMUM RESTARTS 








X 
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DECnet PARAMETER SUMMARY 



Table A-9 Module X25-PROTOCOL Parameters (Cont.) 



Digital Network Architecture 


DECnet- 10V4.0 Implementation 


Parameter 
Number 


NCP Keywords 


Applicability 


Restrictions 


TOP&-10 MCB Restrictions 


1160 


CALL TIMER 






X 


1161 


CLEAR TIMER 






X 


1162 


RESET TIMER 






X 


1163 


RESTART TIMER 






X 


1170 


DTE 


Qualified by GROUP 




X 


1171 


NUMBER 


Qualified by GROUP 




X 


1172 


TYPE 

1 BILATERAL 


Qualified by GROUP 




X 



Some DTE parameters can be set only when the DTE is off. 



Table A-10: Module X25-SERVER Parameters 



Digital Network Architecture 


DECnet-10V4.0 Implementation 


Parameter 
Number 


NCP Keywords 


Applicability 


Restrictions 


TOPS- 10 MCB Restrictions 


100 


COUNTER TIMER 






X 


200 


ACTIVE CIRCUITS 




Display only 


X 


300 


DESTINATION 


Qualifying parameter 




X 


310 


MAXIMUM CIRCUITS 






X Display only in MCB 


320 


NODE 
Node address 
Node name (if any) 


Qualified parameter 




X 


330 


USER user 


Qualified parameter 




X 


331 


PASSWORD (to set) 
Password set 


Qualified parameter 


Set only 


X 


331 


PASSWORD (to read) 
Password set 


Qualified parameter 


Display only 




332 


ACCOUNT 


Qualified parameter 




X 


340 


OBJECT 
object number 
object name 


Qualified parameter 




X 


350 


PRIORITY 


Qualified parameter 




X 


351 


CALL MASK 


Qualified parameter 




X 


352 


CALL VALUE 


Qualified parameter 




X 


353 


GROUP 


Qualified parameter 




X 


354 


NUMBER 


Qualified parameter 




X 


355 


SUBADDRESSES 
Range beginning 
Range end 
(none if same 
as beginning) 


Qualified parameter 




X 
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APPENDIX B 
COUNTER SUMMARY 



This appendix contains the entity counters that may be zeroed or 
displayed by the appropriate NCP commands (ZERO and SHOW), Section 
B.l lists DECnet-10 specific counters, and Section B.2 lists DECnet-10 
PSI specific counters. Section B.3 describes all counters in textual 
detail. 



B.l DECnet COUNTER SUMMARY 

This counter summary is specific to DECnet-10 Version 4.0. See the 
appropriate documentation for other DIGITAL operating systems for 
counter text displayed and counters zeroed. 



Table B-1: DECnet-10 Specific Counters 



ALL COUNTERS (NODE, LINE, AND CIRCUIT) 


Maintained By 
Network Management 


Counter Text 

Seconds since last zeroed 


NODE COUNTERS 




Maintained By 
Network Services 

Routing 

(Executor node only) 


Counter Text 

Bytes received 

Bytes sent 

Messages received 

Messages sent 

Connects received 

Connects sent 

Response timeouts 

Received connect resource errors 

Aged packet loss 
Node unreachable packet loss 
Node out-of-range packet loss 
Oversized packet loss 
Packet format errors 
Partial routing update loss 
Verification reject 
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Table B-1: DECnet-10 Specific Counters (Cont.) 



LINE COUNTERS (for MCB lines) 




Maintained By 
Physical Link 


Counter Text 

Remote Process Errors 
Local Process Errors 


CIRCUIT COUNTERS 




Maintained By 
Routing 

Data Link 


Counter Text 

Terminating Packets Received 
Originating Packets Sent 
Terminating Congestion Loss 
Transit Packets Received 
Transit Packets Sent 
Transit Congestion Loss 
Circuit Downs 
Initialization Failures 
Bytes Received 
Bytes Sent 

Data Blocks Received 
Data Blocks Sent 

Data Error Inbound, including: 
NAKs Sent, Header Block Check Error 
NAKs Sent, REP Response 

Data Errors Outbound 

Remote Reply Timeouts 

Local Reply Timeouts 

Remote Buffer Errors 

Local Buffer Errors 

Selection Intervals Elapsed 

Selection Timeouts 



B.2 X.25 SPECIFIC COUNTERS 

The following tables describe X,25 specific counters for the PSI 
Version 1.0 software option. 

The following table specifies the Data Link counters that apply to 
permanent X.25 circuits. 

Table B-2: Data Link Circuit Counters for Permanent X.25 Circuits 



Type 


Bit 




Number 


Width 


Standard Text 





16 


Seconds since last zeroed 


1000 


32 


Bytes received 


1001 


32 


Bytes sent 


1010 


32 


Data blocks received 


1011 


32 


Data blocks sent 


1240 


8 


Locally initiated resets 


1241 


8 


Remotely initiated resets 


1242 


8 


Network initiated resets 
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The following table specifies the Data Link counters for LAPB lines. 



Table B-3: Data Link Line Counters for LAPB Lines 



Type 


Bit 




Bit Number 


Number 


Width 


Standard Text 


Standard Text 





16 


Seconds since last zeroed 




1000 


32 


Bytes received 




1001 


32 


Bytes sent 




1010 


32 


Data blocks received 




1011 


32 


Data blocks sent 




1020 


8 


Data errors inbound 


3 Block too long 

4 Block check error 

5 REJ sent 


1021 


8 


Data errors outbound 


3 REJ received 


1030 


8 


Remote reply timeouts 




1031 


8 


Local reply timeouts 




1040 


8 


Remote buffer errors 


2 RNR received, 
buffer 
unavailable 


1041 


8 


Local buffer errors 


2 RNR sent, 
buffer 
unavailable 


1100 


8 


Remote process errors 


4 Invalid N(R) 
received 

5 FRMR sent, 
header format 
error 


1101 


8 


Local process error 


2 Transmit underrun 

4 Receive overrun 

5 FRMR received, 
head format error 



The following table specifies 
counters. 



the X.25 protocol module local DTE 



Table B-4 ; X.25 Protocol Module Counters 



Type 


Bit 




Number 


Width 


Standard Text 





16 


Seconds since last zeroed 


1000 


32 


Bytes received 


1001 


32 


Bytes sent 


1010 


32 


Data blocks received 


1011 


32 


Data blocks sent 


1200 


16 


Calls received 


1201 


16 


Calls sent 


1210 


16 


Fast selects received 


1211 


16 


Fast selects sent 


1220 


16 


Maximum switched circuits active 


1221 


16 


Maximum channels active 


1230 


16 


Received call resource errors 


1240 


8 


Locally initiated resets 


1241 


8 


Remotely initiated resets 


1242 


8 


Network initiated resets 


1250 


8 


Restarts 
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The following table specifies the X.25 server module counters. 



Table B-5: X.25 Server Module Counters 



Type 
Number 


Bit 
Width 


Standard Text 



200 
210 
211 


16 

16 

8 

8 


Seconds since last zeroed 

Maximum circuits active 

Incoming calls rejected, no resources 

Logical links rejected, no resources 



B.3 COUNTER DESCRIPTIONS 

Counters are listed in the same order that they appear in the NCP SHOW 
command. 



B.3.1 Circuit Counters 

This section contains a description of each circuit counter. 
(Includes the data link circuit counters for permanent X.25 circuits 
and counters for Ethernet and PSI operations.) 

Seconds since last zeroed 

This counter indicates the number of seconds that elapsed since 
the circuit counters were zeroed. This counter provides a time 
frame for other counter values. The software increments this 
counter every second and clears it when other counters are 
cleared. Applies also to MCB PSI operations. 

Terminating packets received 

This counter indicates the number of data packets received by the 
Routing layer on the local node. 

Originating packets sent 

This counter indicates the number of data packets sent by the 
Routing layer on the local node. 

Terminating congestion loss 

This counter indicates the number of packets intended for the 
node that were discarded because Routing could not buffer them. 

Transit packets received 

This counter indicates the number of data packets received over 
the circuit and to be routed through the local node to another 
node. It is maintained only on full-routing nodes. 

Transit packets sent 

This counter indicates the number of data packets sent over the 
circuit and being routed through the local node to another node. 
It is maintained only on full-routing nodes. 
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Transit congestion loss 

This counter indicates the number of transit data packets 
discarded for congestion reasons. This counter is maintained 
only on full-routing nodes. If congestion loss increases, 
increase the MAXIMUM BUFFERS parameter for the local node. 

Circuit downs 

This counter indicates the number of failures - operator or 
software induced - for the circuit. These failures may include 
any number of hardware-, software-, or operator-caused problems. 
This counter corresponds to events 4.7-9 (circuit down). 

Initialization failures 

This counter indicates the number of times the circuit failed to 
initialize with remote Routing software. These failures may 
include any number of hardware-, software-, or operator-caused 
problems. This counter corresponds to events 4.11-13 
(initialization failure) . 

Transmit packets discarded-blocksize exceeded 

This counter indicates the number of packets discarded by the 
local node because the packet was larger than the local node's 
buffer size. This occurs when the node has a buffer size that is 
greater than 576 bytes for Ethernet communications and the 
Ethernet goes down. The Router attempts to send the 
"Ethernet-sized" packets through a line with a small buffer size, 
forcing the packets to be discarded. 

Bytes received 

This counter indicates the number of bytes of data received by 
the local node over the circuit. You can use this information 
together with the data blocks received counter to determine the 
inbound traffic load. Applies also to MCB PSI operations. 

Bytes sent 

This counter indicates the number of bytes of data sent by the 
local node over the circuit. You can use this information 
together with the data blocks sent counter to determine the 
outbound traffic load. Applies also to MCB PSI operations. 

Data blocks received 

This counter indicates the number of data blocks received by t:he 
local node. You can use this information as a statistical bese 
when evaluating the number of inbound data errors, remote reply 
timeouts, and local buffer errors. Applies also to TOPS-10 PSI 
operations. 

Data blocks sent 

This counter indicates the number of data blocks sent by the 
local node. You can use this information as a statistical bese 
when evaluating the number of outbound data errors, local reply 
timeouts, and remote buffer errors. Applies also to Ethernet cind 
TOPS-10 PSI operations. 
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Data errors inbound 

This counter indicates the number of data errors that normally 
result from errors on the inbound communications channel to the 
local node. These errors are caused usually by a noisy 
communications line or a poorly functioning modem. This counter 
may include either or both of the following qualifiers if they 
contribute to two errors: 

o NAKs sent, header block check error 

o NAKs sent, data field block check error 

User buffer unavailable 

This counter indicates the total number of times that no user 
buffer was available. 

Locally initiated resets 

This counter indicates the number of resets sent over the 
circuit. Applies only to MCB PSI operations. 

Remotely initiated resets 

This counter indicates the number of resets received over the 
circuit. Applies only to MCB PSI operations. 

Network initiated resets 

This counter indicates the number of resets originated by the 
PSDN received over the circuit. Applies only to MCB PSI 
operations. 



B.3.2 Line Counters 

This section contains a description of each line counter. (Includes 
the PSI data link line and counters for LAPB lines.) 

Seconds since last zeroed 

This counter indicates the number of seconds that elapsed since 
the line counters were zeroed. This counter provides a time 
frame for other counter values. The software increments this 
counter every second and clears it when other counters are 
cleared. 

Blocks sent, initially deferred 

This counter indicates the total number of times that a frame 
transmission was deferred on its first transmission attempt. 
Used in measuring Ethernet contention with no collisions. 

Blocks sent, multiple collisions 

This counter indicates the total number of times that a frame was 
successfully transmitted on the third or later attempt after 
normal collisions on previous attempts. Applies only to Ethernet 
operations. 
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Blocks sent, single collision 

This counter indicates the total number of times that a frame was 
successfully transmitted on the second attempt after a nornal 
collision on the first attempt. Applies only to Ethernet 
operations. 

Bytes received 

This counter indicates the number of bytes of data received over 
the line. Applies to Ethernet and MCB PSI operations. 

Bytes sent 

This counter indicates the number of bytes of data sent over the 
line. Applies to Ethernet and MCB PSI operations. 

Data blocks received 

This counter indicates the number of blocks received over the 
line. Applies to Ethernet and MCB PSI operations. 

Data blocks sent 

This counter indicates the number of data blocks sent over the 
line. Applies to Ethernet and MCB PSI operations. 

Data errors inbound 

This counter indicates the number of incoming data errors that 
result from faults on the channel between the local DTE and DCE. 
The counter can include up to three of the following qual if ier*.3. 

Block too long 
Block check error 
Reject sent 

Applies only to MCB PSI operations. 

Data errors outbound 

This counter indicates the number of outgoing data errors tliat 
result from faults on the channel between the local DTE and DCJE. 
The counter can include the following qualifier. 

Reject received 

Applies only to MCB PSI operations. 

Data overrun 

This counter indicates the total number of times the hardware 
lost an incoming frame because it was unable to keep up with l:he 
data rate. 

Multicast bytes received 

This counter indicates the total number of multicast data byl:es 
successfully received (includes bytes in Ethernet data field but 
not the Ethernet data link headers) . 
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Send failures 

This counter indicates the total number of times a transmit 
attempt failed. For each increment of the counter, a type of 
failure is recorded, as follows: 

Excessive collisions 

Carrier check failed 

Short circuit 

Open circuit 

Frame too long 

Remote failure to defer 

Transmit buffer parity (NIA20) 

Carrier detect failed 

Applies only to Ethernet operations. 

Receive failures 

This counter indicates the total number of blocks received with 
some data errors (the blocks are data frames that passed either 
physical or multicast address comparison) . For each increment of 
the counter, a type of failure is recorded, as follows; 

Block check error 

Framing error 

Frame too long 

No free buffers 

Free list parity error (NIA20) 

Applies only to Ethernet operations. 

Local reply timeouts 

This counter indicates the number of times that a frame with a 
poll bit set has been received over the line; that is, the number 
of errors that result from faults on the line. Applies only to 
MCB PSI operations. 

Remote reply timeouts 

This counter indicates the number of times that the retransmit 
timer for that line has expired. The retransmit timer can expire 
for any of the following reasons: 

1. The line is not connected to a modem 

2. The X.25 network is not responding fast enough 

3. The retransmit timer is set too low 
Applies only to MCB PSI operations. 

Remote buffer errors 

This counter indicates the number of receive-not-ready (RNR) 
frames received. The counter can include the following qualifer: 

RNR received, buffer unavailable 

Applies only to MCB PSI operations. 
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Local buffer errors 

This counter indicates the number of receive-not-ready (RHR) 
frames sent. The counter can include the following qualifier: 

RNR sent, buffer unavailable 

Applies only to MCB PSI operations. 

Remote process errors 

This counter indicates an invalid n(R) and a frame reject (FRMR) 
sent over the line. The counter can include the following 
qualifiers: 

Invalid n(R) received 

FRMR sent, header format error 

These errors usually indicate that the DCE is functioning 
incorrectly. Applies only to MCB PSI operations. 

Local process errors 

This counter indicates that a frame reject (FRMR) has boen 
received over the line or that your system is being overloadesd. 
The counter can include the following qualifiers: 

Transmit underrun 

Receive overrun 

FRMR received, header format error 

The first two qualifiers usually indicate that the system is 
overloaded and the third usually indicates that the MCB PSI 
software is functioning incorrectly. Applies only to MCB PSI 
operations. 

Unrecognized frame destination 

This counter indicates the number of times a frame was discarded 
because there was no portal with the protocol type or multiccist 
address enabled. The count includes frames received for t:he 
physical address, broadcast address, or multicast address. 



B.3.3 Node Counters 

This section contains a description of each node counter. 

Seconds since last zeroed 

This counter indicates the number of seconds that elapsed since 
the node counters were zeroed. It provides a time frame f:or 
other counter values. The software increments this counter every 
second and clears it when other counters are cleared. 

User bytes received 

This counter indicates the number of user data bytes received 
from a remote node. This includes interrupt messages, but 
excludes Connect, Accept, Reject, and Disconnect messages. 
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User bytes sent 

This counter indicates the number of user data bytes sent to a 
remote node. 

User messages received 

This counter indicates the number of NSP messages carrying user 
data that were received from a remote node. 

User messages sent 

This counter indicates the number of NSP messages carrying user 
data that were sent to a remote node. 

Total bytes received 

This counter indicates the number of user data bytes received 
from a remote node plus the NCP protocol bytes and the overhead 
bytes, including Connect, Accept, Reject, and Disconnect 
messages. 

Total bytes sent 

This counter indicates the number of user data bytes sent to a 
remote node plus the NSP protocol bytes and the overhead bytes, 
including Connect, Accept, Reject, and Disconnect messages. 

Total messages received 

This counter indicates the number of NSP (Network Services 
Program) messages received from a remote node including the 
overhead messages. 

Total messages sent 

This counter indicates the number of NSP (Network Services 
Program) messages sent to a remote node including the overhead 
messages. 

Connects received 

This counter indicates the number of logical link connection 
requests received by the local node. 

Connects sent 

This counter indicates the number of logical link connection 
requests sent by the local node. 

Response timeouts 

This counter indicates the number of times there was no response 
to an NSP segment within the allotted timeout period. This 
implies that the local node has to retransmit messages. Such 
retransmission can be caused either by messages being discarded 
in the network or by a wide variance in the round-trip delay to 
the node. Normally, it indicates an overload condition in the 
network. 
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Received connect resource errors 

This counter indicates the number of inbound connect messages for 
which the local node did not have sufficient resources. These 
errors may result from dynamic memory problems or too few logical 
link slots; that is, the MAXIMUM LINKS parameter value is too 
small. 

Maximum logical links active 

This counter indicates the largest number of logical link that 
have been active since DECnet-10 software was started or since 
executor counters were zeroed. 

Aged packet loss 

This counter indicates the number of data packets discarded for 
visiting too many nodes. This usually occurs while the databases 
throughout the network are recovering from a disruption (for 
example, when a circuit or line goes down) in the former path bo 
a destination. This counter is maintained only on full-routing 
nodes and corresponds to event 4.0 (aged packet loss). 

Node unreachable packet loss 

This counter indicates the number of data packets lost because 
the destination node could not be accessed. This counter Is 
maintained only on full routing nodes. This counter corresponds 
to event 4,1 (node unreachable packet loss). 

Node out-of-range packet loss 

This counter indicates the number of data packets discarded 
because the destination node's address is greater than the 
maximum address defined for the local node. This counter 
corresponds to event 4.2 (node out-of-range packet loss). 

Oversized packet loss 

This counter indicates the number of received data packets that 
were too large to forward because of the block size of the da:a 
link that would be used. This counter is maintained only on 
full-routing nodes, and corresponds to event 4,3 (oversized 
packet loss) . 

Packet format error 

This counter indicates the number of packet format errors that 
occur because of invalid packet control information. This 
counter corresponds to event 4.4 (packet format error). 

Partial routing update loss 

This counter indicates the number of received routing messages 
that were too long to process. Part of a routing update may be 
lost if it contains a reachable node with an address greater than 
the maximum address defined for the local node. This counter is 
maintained only on full-routing nodes, and corresponds to event 
4,5 (partial routing update loss). 

Verification reject 

This counter indicates the number of received verification 
messages that were invalid. It corresponds to event 4,6 
(verification reject) , 
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B,3,4 X.25 Protocol Module Counters 

This section contains a description of each X.25 protocol module 
counter. These counters apply only to MCB PSI operations. 

Seconds since last zeroed 

This counter indicates the number of seconds that have elapsed 
since the module counters were zeroed. This counter provides a 
time frame for other counter values. The MCB PSI software 
increments this counter every second and clears it when the 
counters are zeroed. 

Bytes received 

This counter indicates the number of bytes of data received by 
the local DTE. You can use this information together with the 
data blocks received counter to determine the total traffic load. 

Bytes sent 

This counter indicates the number of bytes of data sent by the 
local DTE. You can use this information together with the data 
blocks sent counter to determine the total traffic load. 

Data blocks received 

This counter indicates the number of data blocks received by the 
local DTE. 

Data blocks sent 

This counter indicates the number of data blocks sent by the 
local DTE. 

Calls received 

This counter indicates the number of incoming calls received. 
Calls sent 

This counter indicates the number of outgoing calls made. 

Fast selects received 

This counter indicates the number of calls received with the fast 
select facility specified. 

Fast selects sent 

This counter indicates the number of calls sent with the fast 
select facility specified. 

Maximum switched circuits active 

This counter indicates the number of switched virtual circuits 
that were active at any one time since the counters were last 
zeroed. 

Maximum channels active 

This counter indicates the maximum number of channels from the 
logical channels list that were active at any one time since the 
counters were last logged. 
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These circuits are ones whose logical channel numbers appear in 
the channels list regardless of whether the circuits are used for 
incoming or outgoing calls. 

Received call resource errors 

This counter indicates the number of times an incoming call l-ias 
been rejected because of insufficient resources or an incorrect 
configuration (for example, no destination or object specified). 

Locally initiated resets 

This counter indicates the number of resets sent by the local 
DTE. 

Network initiated resets 

This counter indicates the number of resets (originated by t;he 
PSDN ) received by the local DTE. 

Remotely initiated resets 

This counter indicates the number of resets (originated by a 
remote DTE or DTEs) received by the local DTE. 

Restarts 

This counter indicates the number of times that the restcirt 
protocol procedure was used on the DTE. 



B.3.5 X.25 Server Module Counters 

This section contains a description of each X,25 server module 
counter. These counters apply only to TOPS-10 PSI operations. 

Seconds since last zeroed 

This counter indicates the number of seconds that have elapsed 
since the module counters were zeroed. This counter provides! a 
time frame for other counter values. The TOPS-10 PSI softwcire 
increments this counter every second and clears it when t;he 
counters are zeroed. 

Maximum circuits active 

This counter indicates the number of switched virtual circuits 
that have been set up since the counters were last zeroed. 

Incoming calls rejected, no resources 

This counter indicates the number of times the incoming ccill 
handler rejected a request to set up a virtual circuit because of 
insufficient resources. 

Logical links rejected, no resources 

This counter indicates the number of X.25 circuits that have beien 
set up by the TOPS-10 host system but rejected by the MCB because 
of insufficient resources at the Gateway. 
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APPENDIX C 
NETWORK RELATED MESSAGES 



When you are using NCP commands, messages related to the execution of 
the commands and to the condition of the network are output. Scime 
appear on the user's terminal, and some appear on the CTY. If you cire 
the system manager, you should check the network-related messages on 
the CTY, or delegate this responsibility. If you are an 
operator-user, you should resolve those messages output to yciur 
terminal. Only those messages output to the user's terminal cire 
described in this appendix (see also Section 4.5.6). 



C.l OPR/NCP COMMAND SYNTAX MESSAGES 

All NCP messages are first examined by OPR. OPR uses the NCP table to 
check the command syntax. The parsed command is then sent in an IPCF 
packet to ORION and QUASAR, where further errors or informational 
messages can be added. The completely checked command returns to OPR 
and OPR directs all messages on each command to the terminal where you 
type the NCP command. 

The syntax messages output by OPR all begin with a question mark (?) 
and are in readable text only (no codes or abbreviations) . In those 
messages the "?" does not indicate a fatal error: it questions the 
accuracy of your input. You correct the command by retyping up to the 
point of error (use CTRL/H) and substituting or adding the corroct 
keyword or value. If you are unsure of what is required, typo a 
question mark to get a list of possible arguments. 

Possible syntax error messages follow in alphabetic order. Several 
examples of NCP commands with errors, showing the desired corrections, 
follow the alphabetic list. 

? Ambiguous 

? Does not match switch or keyword: "word" 

? Filename was not specified 

? File not found 

? First nonspace character is not a digit 

? Invalid character in number 

? Invalid device terminator 

? Invalid guide word 

? Invalid node name 
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? Invalid wildcard designator 

? Negative number improper 

? No help available for "word" 

? No such file type 

? Node name doesn't contain any alphabetic characters 

? Not confirmed 

? Null switch or keyword given 

? Too many characters in node name 

? Unrecognized switch or keyword: "word" 

Examples: 

NCP>SET EXECTOR NODE D2102A<RET> 

? Unrecognized switch or keyword: "exector" 

NCP>SET EXECUTOR NODE D2102A<RET> 

NCP> 

10:21:26 NCP 

Set Executor Complete 

NCP>SET EXECUTOR INACTIVITY TIMER SECONDS 20<RET> 

?First nonspace character is not a digit 

NCP><CTRL/H> 

NCP>SET EXECUTOR INACTIVITY TIMER20<RET> 

? Unrecognized switch or keyword: "timer20" 

NCP><CTRL/H> 

NCP>SET EXECUTOR INACTIVITY TIMER 20<RET> 

NCP> 

11:35:35 NCP 

Set Node Complete 

C.2 OPR/ORION/QUASAR INFORMATIONAL MESSAGES 

Informational messages report major system changes: they cannot be 
"REFUSED" or "DISABLED," Depending on your current needs, these 
messages may or may not concern you, but you should read them. 

Such messages are always time-stamped and have the general format: 

NCP> 

hh:mm:ss — text 

An example of an informational message of interest to network users 
follows: 

Example: 

NCP> 

16:17:44 — NCP is not running — 
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NCP commands that are syntactically correct (no errors reported 
through OPR) are executed immediately if they do not require use of 
the NICE protocol. This includes the OPR/NCP commands (described in 
Chapter 5) and the commands processed locally by NCP (described in 
Chapter 6). These commands that are not sent in NICE protocol 
messages receive only the messages described in Sections C.l and C.2. 



C.3 NCP COMMAND RESPONSE MESSAGES 

All commands processed by Network Management routines are assigned a 
request number by NCP. They are then translated into NICE messages 
and forwarded to NML in the central processor for local processing or 
to NML in the remote node for remote processing. Results of this 
processing return to the local NCP by means of NICE messages, which 
are then formatted into response messages. 

The generic format of NCP command response messages is; 



hh:mm;ss 
where: 



NCP 

Request # nnn; command entity status, [error information] 



hh:mm:ss 

nnn 

command 

entity 

status 



is the time in hours, minutes, and seconds 

is the request number assigned 

is a command indicator 

is a specific entity 

is one of Complete, Accepted, or Failed 



error information is displayed only if status is Failed 
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C.3.1 Status Messages 

Status is reported as Complete if the command has executed 
successfully. Status reported as Accepted implies only that the 
command is semantically (and syntactically) correct; the command 
receives a further response of Complete or Failed when it is executed. 
If the status is reported as Failed, an error message follows. 

Examples : 

NCP>SH KN NO STA<RET> 
NCP> 

9:37:29 NCP 
Request # 96; Show Known Node Status Completed 
Remote Node = 7.88 (KL2530) 
State = Unreachable 

********** 



NCP>CLEAR EXEC<RET> 
NCP>LOA NO D2102A<RET> 
NCP> 
11:18:16 NCP 

Clear Executor Complete 

11:18:16 NCP 

Request # 2 Accepted 

11:18:19 NCP 

Request # 2; Load Node Completed 
********** 

NCP>SH NO XXYZZ CH<RET> 
NCP> 

11:00:17 NCP 
Request # 13; Show Node Failed, Unrecognized component 
Entity = Node 
Node = (XXYZZ) 



C.3.2 Error Messages from Network Management Software 

When the status is Failed, an error message gives the reason for the 
failure. This reason is followed by detail if such detail is 
available. The detail, in turn, can be followed by additional 
explanatory text. 

NCP error messages are listed below in alphabetic order, A brief 
explanation is given; where possible, appropriate action is suggested. 
The following NCP error messages are standard for most DECnet 
implementations. Since NICE errors only return an error code and not 
the error message text, the NICE return codes are also listed. 
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Error Message Text 

Bad loopback response 
NICE error code (-28) 



Component in wrong state 
NICE error code (-11) 



Description/Procedures 

The message returned in a loopback 
test did not match the message 
sent. Repeat the loopback test. 
If the error persists, use the 
various loopback tests to try to 
isolate the part of the line that 
is bad. Follow your site's 
procedures for notifying your Field 
Service Representative. 

There is a problem with the state 
of the entity to which the command 
applies, or to the secondary entity 
(line, for example, in a LOAD 
command) . Check the state of the 
primary and secondary entities. 
Are nodes or lines ON, OFF, or in 
SERVICE state as required by the 
function being requested? Correct 
and try again. 



File I/O error 

NICE error code (-18) 



A hardware error occurred while 
trying to read or write a file 
required to execute the command. 
The error detail indicates the 
problem is in one of the following: 

DUMP FILE 
LOAD FILE 

Permanent Data Base 
SECONDARY DUMPER 
SECONDARY LOADER 
TERTIARY LOADER 
Volatile Data Base 



Repeat the command, 
persists, follow 
standard procedure 
hardware errors. 



If the error 

your site's 

for reporting 



File open error 

NICE error code (-13) 



A file needed for processing could 
not be opened. Error detail 
specifies same files as for "File 
I/O error." System-specific detail, 
if present, may suggest procedure. 
If no detail is given, check 
directory or file restrictions. 



Hardware failure 
NICE error code (-24) 



The hardware needed 
request could not 
function requested, 
the error message 
check the hardwar 
errors (not up, 
printer, and the lik 
appear to be in orde 
standard rules for 
Field Service Repres 



to satisfy the 

perform the 

Try again. If 

is repeated, 

e for obvious 

no paper in 

e) . If devices 

r, follow your 

contacting your 

entative. 
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Error Message Text 

Incompatible Management version 
NICE error code (-7) 



Invalid file contents 
NICE error code (-14) 



Description/Procedures 

The function requested cannot be 
performed because the version skew 
between the NMLs in the source and 
destination nodes is too great. 
This problem cannot be solved. 
Make a record of the 
incompatibility for the future. 

The error detail indicates the file 
that contains invalid information. 
The file is one of: 



Permanent Data Base 
LOAD FILE 
SECONDARY LOADER 
TERTIARY LOADER 

Although DECnet-10 does not 
currently support a permanent data 
base, you can receive this message 
if you have another node acting as 
executor. 



If the file 
file, the 
remote site 
the file is 
check to be 
is the cor 
next check 
TOPS-10 Ope 



in erro 

system 

should 

local , 
sure th 
rect f 

the d 
rating 



Manual describes th 
follow. 



r is a remote 

manager at the 

be notified. If 

the user should 

e filename typed 

ile. If it was, 

irectory. The 

System Commands 

e procedures to 



Invalid identification 
NICE error code (-9) 



The format of the primary or 
secondary entity identification is 
invalid. The error detail 
indicates identity type. Correct 
the error. 



Invalid message format 
NICE error code (-2) 



NML has received a message that is 
not properly formatted. This could 
indicate a problem with the 
software on either the transmitting 
or receiving end. Try the command 
again. If the error persists, 
follow procedures for a Software 
Performance Report (SPR) . 
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Error Message Text 

Invalid parameter grouping 
NICE error code (-27) 



Invalid parameter value 
NICE error code (-16) 



Description/Procedures 

A request to change multiple 
parameters included an entity 
parameter group that could not be 
changed - the command was not 
executed. Check all 

entity-parameter combinations for 
validity, completeness, and an 
in-bounds value. Are there any 
contradictions or duplications? 
DECnet-10 does not accept 
multiple-parameter commands. Each 
parameter must be in a separate 
command. Repeat specifying one 
parameter per command. 

The error detail indicates the name 
of the invalid parameter. Check 
the range of length, size, and 
number values. Is the value 
permitted with the entity to which 
it refers? 



Line communication error 
NICE error code (-10) 



Line protocol error 
NICE error code (-17) 



This error occurs only on direct 
use of a line such as for looping, 
downline load, or upline dump. The 
error can be in transmitting or in 
receiving. If further detail is 
given, the device may be specified. 
Check (or have the system operator 
check) the operating condition of 
the indicated device. If the 
problem remains, follow procedures 
for reporting to your Field Service 
Representative. 

This error can refer to the Data 
Link protocol or the Service 
Operation protocol. The error is 
given only on direct use of a line 
(as for a line loop or downline 
load). Repeat the command. If the 
error persists, follow procedures 
for a Software Performance Report 
(SPR) . 
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Error Message Text 
Listener link connect failed 



Description/Procedures 

A connect to the NML NICE Listener 
could not be completed. Error 
detail will vary depending upon the 
operating system being connected 
to. Be guided by detail, if 
present. There are several 
possible conditions that could 
cause this error: 



The remote node name or the access 
control information is incorrect. 
Correct the error and repeat the 
command. 

The remote node or the local node 
is in the process of shutting down 
and will accept no more logical 
link connections. Try later. 

Either the local or remote node has 
insufficient network resources to 
connect the logical link. Try 
later. 



Listener link disconnected 



There is no path to the remote 
node. Check the status of the 
remote node (use the SHOW NODE 
nodeid STATUS command) . If status 
is "Unreachable" wait until it is 
"Reachable" and try again. 

A remote node you wish to connect 
to may not have a Network 
Management 

Listener. A connection is not 
possible. Note for future 
reference. The procedure you use 
following this message depends on 
detail given. If the detail 
indicates an easily correctable 
cause, missing or invalid 
parameters, for example, correct 
and repeat the command. If the 
detail suggests a transient 
problem, wait appropriately and try 
again later ("appropriately" might 
be when a remote node comes back on 
line, depending on the reason for 
the failure to connect) . 

A successful connection to the NML 
NICE Listener was made, but the 
logical link then failed. Both the 
error detail and the procedure are 
as described for "Listener link 
connect failed." 
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Error Message Text 

Management program error 
NICE error code (-5) 



Mirror connect failed 
NICE error code (-21) 



Description/Procedures 

A software error in the DECnet-10 
software was detected. A 
system-level message may supply 
detail. Follow procedures for a 
Software Performance Report ( SPR) . 

A connect to the NML Loopback 
Mirror could not be completed. 
Error detail and procedure as for 
"Listener link connect failed." 



Mirror link disconnected 
NICE error code (-19) 



A successful link was made to the 
Loopback Mirror, but the link was 
then disconnected. Error detail 
and procedure as for "Listener link 
connect failed." 



No room for new entry 
NICE error code (-20) 



Operation failure 
NICE error code (-25) 



Oversized management 
command message 
NICE error code (-4) 



Parameter missing 
NICE error code (-29) 



Insufficient room exists in some 
data base for an entry required by 
the requested function. 

A requested operation failed. NML 
supplies no detail; there may or 
may not be system-level or 
system-specific detail. In the 
absence of detail, check the 
following; correct if possible, and 
try again. If the error persists, 
follow procedures for contacting 
your Software Specialist. 

Check to see if there is a required 
parameter for this command that is 
missing or invalid. 

Check to see if the executor in the 
proper state. 

Check to see if are any helpful 
messages on the CTY. 

A message size was too long. The 
NICE message was too long for the 
Management Listener to receive. 
Follow procedures for a Software 
Performance Report (SPR) . 

You failed to include a required 
parameter. The error detail will 
specify the name of the missing 
parameter. Repeat the command with 
the required parameter. 
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Error Message Text 

Parameter not applicable 
NICE error code (-22) 



Parameter value too long 
NICE error code (-23) 



Description/Procedures 

You have included a parameter that 
is not allowed with the entity to 
which it refers. The parameter is 
named in the error detail. Correct 
and repeat the command. 

You have included a parameter that 
is too long to be accepted by the 
implementation. The error detail 
identifies the parameter type. If 
the parameter identified is a file 
specification, be aware that 
maximum file length is 
system-specific (VAX/VMS, for 
example, allows a maximum of 64 
characters for a file 
specification; RSX-llM allows a 
maximum of 34) . If the executor is 
not your local node, you may need 
to refer to documentation for the 
executor's operating system. 



Privilege violation 
NICE error code (-3) 



Resource error 

NICE error code (-15) 



You do not have, or have not 
enabled, the privilege required for 
the function you have requested. 

A resource required to perform the 

requested function was not 

available. Repeat the command 
later. 



System-specific Management 
function not supported 
NICE error code (-26) 



Unrecognized component 
NICE error code (-8) 



Unrecognized function or option 
NICE error code (-1) 

Unrecognized parameter type 
NICE error code (-6) 



System-specific functions return 
this message if the executor node 
is running an operating system 
other than the one for which the 
function was implemented. 

An entity (component) is not known 
to the system. The error detail 
indicates the entity. Usually 
caused by an error in typing. Try 
the command again. 

The requested function or option is 
not implemented by the executor. 

The parameter indicated in the 
error detail is not implemented in 
the executor. 
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C,4 EVENT MESSAGES 

C.4.1 Event Class and Type Summary 

Following is a summary of NCP events in terms of their class and type. 
In general, event classes relate to specific layers of the DECnet 
architecture. The event logging components support the event classes 
summarized below. 

Table C-1: EVENT Classes 



EVENT 




Class 


Description 





Network Management Layer 


1 


Applications Layer 


2 


Session Control Layer 


3 


Network Services Layer 


4 


Routing Layer 


5 


Data Link Layer 


6 


Physical Link Layer 


7-31 


Reserved for other common classes 


32-63 


RSTS System specific 


64-95 


RSX System specific 


96-127 


TOPS-10/20 System specific 


128-159 


VMS System specific 


160-191 


RT System specific 


192-223 


CT system specific 


224-255 


Communication server specific 


480-511 


Customer specific 



DECnet-10 logs events only for specific event classes and types. 

If the logging console is enabled, DECnet-10 uses the OPR program to 
display event messages on all operator terminals enabled to received 
messages with the OPR command ENABLE OUTPUT-DISPLAY NCP-MESSAGES, 
which is the default. 

Event messages have the following format: 

event type class. type, event-text 

from node address [ (node-name) ] dd-mmm-yy hh:mm:ss.ms 

component-type, event-qualifiers, . . . 

The event text is a standard text message as described below for each 
event class and type. The message format also includes the source 
node (address and node name, if available) and time stamp for when the 
event occurred. For most events, the message format includes the 
component type and name for which the event applies. Finally, the 
message format may include the cause of the event. 



The following sections describe the event 
layer. The format is: 



class. type 



event-message- text 



messages for each DECnet 



explanation 
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C,4.2 Network Management Layer Events 

The following specific event classes and types are supported for each 
layer. 

0«0 Event records lost 

Events occurred too rapidly for the event logger to buffer 
them. 

0.1 Automatic node counters 

A node counter timer expired, thus prompting this event. 
This message displays the name of the node for which the 
event applies, along with the node counters for that node. 

0.2 Automatic line counters 

A line counter timer expired, thereby producing this event. 
This message displays the name of the line for which the 
event applies, along with the line counters for that line. 

0.3 Automatic service 

An adjacent node requested an automatic circuit service 
operation. This message displays the name of the circuit 
for which the event applies, along with the service function 
performed (load or dump), the status of the operation 
(requested, successful, or failed), the node address, the 
file specification, and the software type. If the operation 
fails, this status includes an NML error message and 
details. 

0.4 Line counters zeroed 

Line counters were zeroed. This message displays the name 
of the line for which the event applies. The event logger 
logs these counters prior to the execution of a request to 
zero them. 

0.5 Node counters zeroed 

Node counters were zeroed. This message displays the name 
of the node for which the event applies. The event logger 
logs these counters prior to the execution of a request to 
zero them. 

0.6 Passive loopback 

The software initiated or terminated a passive loopback test 
on behalf of an adjacent node. This message displays the 
name of the line for which the event applies, along with the 
state of the operation (initiated or terminated). 
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0.7 Aborted service request 

An adjacent node requested a service over a line connected 
to the local node. However, a problem prevented it from 
being processed at the local node. This message displays 
the name of the line for which the event applies, along with 
the reason for the failure. The reason may be one of the 
following: 

Line open error 

NML received an MOP message and was unable to acquire 
control of the line. Either NML did not have the 
privilege to perform the operation or it could not set 
the substate of the line; or the line had another 
owner. 

Line state change by higher level 

The line was preempted by a higher priority function. 
For example, you used NCP to turn the line off. 

Operation failure 

A load or dump operation was started but a failure 
occurred in the loading or dumping process. 

Receive error 

A line error occurred while trying to receive the 
request. 

Receive timeout 

The line message receive timer expired before the 
request could be received from the adjacent node. 
Either the timer was too short, the line error level 
was too great for any message to get through, or the 
adjacent node stopped requesting. 

Unrecognized request 

A message was received but was not recognizable as a 
request for upline dumping, downline loading, or 
passive loopback testing. The adjacent node may be 
running an incompatible version of the line service 
protocol. 

0.8 Automatic counters 

A counter timer for a node, circuit, or line has expired. 
This message displays the name of the component for which 
the event applies, along with the counters for that line. 

0.9 Counters zeroed 

Counters were zeroed for the node, circuit, or line. This 
message displays the name of the component for which the 
event applies. The event logger logs these events prior to 
the execution of a request to zero them. 
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C.4,3 Session Control Layer Events 

2.0 Local node state change 

The operational state of the local node changed because of 
an operator commapd. Note, however, that the transition 
from SHUT to OFF also happens automatically when the last 
logical link is disconnected (under normal operation). 

This message displays the reason for the state change 
(operator command or normal operation) , the old state ON, 
OFF, SHUT, or RESTRICTED), and the new state. 

2.1 Access control reject 

The local node rejected a connection request because of 
invalid access control information. 

This message displays the name and address of the source 
node; the object type number and process ID of the source 
process requesting the connection; the object type number 
and process ID of the destination process to receive the 
connection request; and the invalid access control 
information. 



C.4.4 End Communication Layer Events 

3.0 Invalid message 

NSP received a message that could not be interpreted. This 
may indicate a software malfunction in either the local or 
remote NSP. This message displays the NSP message that was 
invalid. Refer to the Network Services Functional 
Specification for a description of NSP messages. 

3.1 Invalid flow control 

The remote NSP attempted to modify the local flow control 
value in an invalid manner. This may indicate a software 
malfunction in either the local or remote NSP. This message 
displays the current flow control value. Refer to the 
Network Services Functional Specification for a description 
of flow control. 

3.2 Database reused 

The local node received a connection request from a node for 
which there is no counter block. All counter blocks have 
been previously used, and one of the previously used blocks 
is available for this new node. This results in the loss of 
node counters for the node that formerly occupied the 
database entry. 

This message displays the name of the node for which the 
database entry was formerly used, along with the node 
counters for that node. 
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C,4,5 Routing Layer Events 

4.0 Aged packed loss 

Routing discarded a packet because it had visited too many 
nodes. This can be a normal occurrence when the network is 
reconfiguring its routing databases. It can be a failure 
when the MAXIMUM HOPS value is set too small. This can 
cause the MAXIMUM VISITS value to be too small for a path 
that should be usable. 

This message displays the name of the line for which the 
event applies, along with the packet header. This is 
information from the beginning of the packet. For 
non-Ethernet packets, it consists of a hexadecimal byte of 
flags, the decimal destination and source node addresses, 
and a hexadecimal byte of forwarding data. For Ethernet 
packets, it also includes the Ethernet address of the 
destination and source, the service type, and the protocol 
type. Refer to the Routing Functional Specification for 
additional information. 

4.1 Node unreachable packet loss 

Routing discarded a packet because the local node found that 
the destination node was unreachable. This event provides a 
trace of what has happened to packets that are not reaching 
their destination. 

This message displays the name of the line for which the 
event applies, along with the packet header (as described 
for event 4.0) . 

4.2 Node out-of~range packet loss 

Routing discarded a packet because the destination node 
number was greater than the maximum node number known to the 
local node. Typically, this results from the addition of a 
new node to the network without increasing the MAXIMUM 
ADDRESS value on the local node, yet expecting the local 
node to route packets to that node. 

This message displays the name of the line for which the 
event applies, along with the packet header (as described 
for event 4.0) , 

4.3 Oversized packet loss 

Routing discarded the packet because it was too large to 
forward to the appropriate adjacent node. Typically, this 
occurs when the adjacent node's buffer size is too small or 
when the source node sends a packet that is too large. 

This message displays the name of the line over which the 
packet was to be forwarded, along with the packet header (as 
described for event 4.0). 

4.4 Packet format error 

Routing discarded a packet because of a format error in the 
packet header. This usually results from a programming 
error in the packet formatting by the adjacent node, though 
it could result from a line error that was not detected by 
the line protocol. 
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4.5 Partial routing update loss 

Routing received a routing message that contained node 
addresses greater than the maximum address known to the 
local, node. Subsequently, information on these nodes was 
lost. This occurs when the MAXIMUM ADDRESS value on an 
adjacent node has been increased to accommodate more nodes, 
but the local node's value has not increased. 

The message displays the name of the line over which this 
message was received, along with the packet header (as 
described for event 4.0) and the highest node address in the 
routing update that was lost. 

4.6 Verification reject 

An attempt to initialize with another node failed. The 
local node received an invalid password in the verification 
requested of the adjacent node during routing initialization 
over the line. Either the local node expected the wrong 
receive password, or the adjacent node sent the wrong 
transmit password. 

The message displays the name of the line for which the 
event applies, along with the address of the adjacent node 
that failed to initialize. 

4.7 Circuit down, circuit fault 

An error has occurred for the circuit. This message 
displays the name of the circuit for which the event 
applies, along with the reason for the event. The reason 
could be one of the following: 

Adjacent node address change 

The adjacent node changed addresses without going 
through the normal initialization sequence. This is 
also logged when an adjacent node attempts to 
initialize with the local node, but the adjacent node's 
address is not in the database. 

Adjacent node address out of range 

The adjacent node's address is greater than the maximum 
address defined for the local node. This may be caused 
by an incorrectly defined node address or by a failure 
to update the local node's database when a new node was 
added. 

Adjacent node block size too small 

The line block size provided by the adjacent node is 
too small for normal network operation. The block size 
may be set incorrectly at the adjacent node. 

Adjacent node listener receive timeout 

The node has received no message over the data link 
within the last 30 seconds. This usually means that 
the remote node is not running. 
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Adjacent node listener received invalid data 

A test message sent by the adjacent node contained 
invalid Data or corrupted data. This is most likely 
caused by a hardware problem. 

Call failed 

An outgoing SVC call failed. This is an X.25 event. 

Data errors 

The line was declared down by the local node's line 
protocol handler when the line exceeded an error 
threshold. 

Dropped by adjacent node 

The adjacent node was responsible for breaking the 
circuit connection. 

Invalid verification seed value 

A Routing initialization message sent by an adjacent 
node is not formatted properly. This is most likely 
caused by a remote network software problem. 

Line synchronization lost 

The normal line protocol was restarted or terminated by 
the adjacent node. Either a line exceeded an error 
threshold, or network management initiated a line state 
change, DMR/DMC failures that cause a line 
synchronization error are as follows: 

o Threshold errors, including more than eight 
attempts to transmit a message, or eight Ns 
received in a row. 

o Start message received in the RUN state (that is, 
the remote system detected an error and restarted 
the line) , 

o Maintenance requested while in the RUN state (that 
is, the remote system tried to perform a 
maintenance operation such as LOOP CIRCUIT) , 

o Message was lost because no buffer was available in 
CPU memory. 

o Nonexistent memory error. 

o Procedure error, because of driver failure or 
hardware failure. 

o Timeout on request to transmit a message in 255 
seconds. 

o Power failure. 

Routing update checksum error 

A routing update packet failed its internal integrity 
test. 
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Unexpected packet type 

A packet was received out of the normal protocol 

sequence. For example, the local node received a 

normal data packet when it expected a verification 
packet. 

Verification password required from Phase III node 

A required routing initialization password was not 
specified before an attempt was made to initialize the 
Phase III node in a Phase IV network. 

Verification receive timeout 

A required verification packet was not received from 

the adjacent node within the required response time. 

Either packets were lost on the line or a failure 
occurred at the adjacent node. 

Version skew 

The routing version of the adjacent node is 
unacceptable to the local node. The operator may have 
installed incorrect software at the adjacent node. 

4.8 Circuit down 

An error has occurred for the circuit. This message 
displays the name of the circuit for which the event 
applies, along with the packet header (as described for 
event 4.0), the reason (as described for event 4.7), and the 
address of the adjacent node. 

4.9 Circuit down, operator fault 

An operator error has occurred for the circuit. This 
message displays the name of the circuit for which the event 
applies, along with the packet header (as described for 
event 4.0), the reason, (as described for event 4.7) and the 
addresses of the expected node and the adjacent node. 

4.10 Circuit up 

A remote node has initialized on one of the physical lines 
connected to the local node. This message displays the name 
of the line for which the event applies, along with the 
address of the newly initialized node. 

Be sure to note that this event does not imply that the node 
is reachable. Reachability is determined by the 
higher-level routing algorithms, 

4.11 Initialization failure, line fault 

A remote node failed to initialize with the local node 
because of a physical line error. This message displays the 
name of the line for which the event applies, along with the 
reason for the event (as described for event 4.7) 
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4.12 Initialization failure, software fault 

A remote node failed to initialize with the local node 
because of a software error. This message displays the name 
of the line for which the event applies, along with the 
packet header (as described for 4.0) and the reason (as 
described for event 4.7). 

4.13 Initialization failure, operator fault 

A remote node failed to initialize with the local node 
because of an operator error. This message displays the 
name of the line for which the event applies, along with the 
packet header (as described for event 4.0), the reason (as 
described for event 4.7) , and the version received from the 
adjacent node. 

4.14 Node reachability change 

Because of Routing operation, the reachability of a remote 
node has changed. This message displays the name of the 
node for which the event applies, along with the routing 
status of the node (reachable or unreachable). 

4.15 Adjacency up 

The adjacent node on the circuit is initialized. This 
message displays the name of the circuit for which the event 
applies, and the address of the adjacent node. 

4.16 Adjacency rejected 

The adjacent node on the circuit is not initialized. The 
message displays the name of the circuit for which the event 
applies, and the address of the adjacent node and the reason 
for the event (as described for event 4.7). 

4.17 Area reachability change 

Because of Routing operation, the reachability of an area 
has changed. This message displays the name of the area for 
which the event applies, along with the routing status of 
the area (reachable or unreachable). 

4.18 Adjacency down 

An error has occurred for an adjacency on the circuit. This 
message displays the name of the circuit for which the event 
applies, along with the reason (as described for event 4.7) , 
the packet header (as described for event 4.4) , and the 
address of the adjacent node on the circuit. 

4.19 Adjacency down, operator fault 

An adjacency on the circuit is down because of an operator 
error. This message displays the name of the circuit for 
which the event applies, along with the reason (as described 
for event 4.7), the packet header (as described for event 
4.0) , and the addresses of the expected node and the 
adjacent node on the circuit. 
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C.4.6 Data Link Layer Events 

5.0 Locally initiated state change 

The line state changed because of an operator command. This 
message displays the name of the line for which the event 
applies, along with the old DDCMP state (HALTED, ISTRT, 
ASTRT, RUNNING, or MAINTENANCE) and the new DDCMP state. 
Refer to the DDCMP Functional Specification for a 
description of these states. 

5.1 Remotely initiated state change 

A remote user changed the line state. This message displays 
the name of the line for which the event applies, with the 
old and new DDCMP line states (see event 5.0). 

5.2 Protocol restart received in maintenance mode 

The remote node restarted normal operation while the local 
node had the line in maintenance mode. This message 
displays the name of the line for which the event applies. 

5.3 Send error threshold 

Too many data transmission errors occurred. This message 
displays the name of the line for which the event applies, 
along with the line counters for that line and the address 
of the received station (node) . 

5.4 Receive error threshold 

Too many data reception errors occurred. This message 
displays the name of the line for which the event applies, 
along with the line counters for that line and the address 
of the received station (node) . 

5.5 Select error threshold 

Too many selection errors occurred. This message displays 
the name of the line for which the event applies, along with 
the line counters for that line and the address of the 
received station (node) . 

5.6 Block header format error 

DDCMP received an invalid block header. This message 
displays the name of the line for which the event applies, 
along with the invalid block header. Refer to the DDCMP 
Functional Specification for a description of the block 
header format. 

5.7 Selection address error 

The wrong tributary responded in the polling process. The 
event occurs only for a multipoint control station when one 
receives a message that does not match the address of the 
currently selected tributary. 

This message displays the name of the line for which the 
event applies, along with the tributary addresses of the 
selected tributary, the received tributary, and the previous 
tributary. 
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5.8 Streaming tributary 

A tributary on the line is impeding the use of that line. 
This message displays the name of the line for which the 
event applies, along with the tributary address of the 
received tributary and the status of the tributary. The 
status may be any of the following: 

o Streaming 

o Continued send after timeout 

o Continued send after deselect 

o Ended streaming 

5.9 Local buffer too small 

A local buffer is too small for receiving a block of data. 
This message displays the name of the line for which the 

event applies, along with two qualifiers the length (in 

bytes) of the received block and the length (in bytes) of 
the buffer. 

5.10 Restart (X.25 protocol) 

A restart occured at the frame level in the X.25 Gateway. 

5.11 State change (X.25 protocol) 

The operational state of the X.25 line changed because of an 
operator command or a communication loss with the packet 
switch network. 

5.13 Line initialization failure 

An initialization failure occurred over an Ethernet line. 
This message displays the name of the line for which the 
event applies. 

5.14 Send failure on line * 

A data transmission attempt failed on an Ethernet line. 
This message displays the name of the line for which the 
event applies, along with the reason for the failure and the 
distance. Failure reasons can include excessive collisions, 
short or open circuits, too long a frame, a framing error, 
an unrecognized frame destination, a remote failure to 
defer, a block check error, or data overrun. 

5.15 Receive failed on line * 

Data was not received on an Ethernet line. This message 
displays the name of the line for which the event applies, 

along with two event qualifiers the reason for the failure 

(as described in event 5.14) and the Ethernet header which 
includes the source and destination node addresses and the 
protocol type. 
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5.16 Collision detect check failed on line 



A check for collision detection failed on an Ethernet line. 
The message displays the name of the line for which the 
event applies. 



5.17 DTE up 



From node 7.99 (NONAME) , 15-Apr il-1984 18:36:34:04 DTE = 
311060300052 



5.18 DTE down 



From node 7.99 (NONAME), 15-Apr il~1984 18:36:25:89 DTE = 
311060300052 
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D.l MANAGING X29SRV 

The system manager can tailor the characteristics of X29SRV to suit 
the requirements of the site by using variations of the DEFINE 
command. The commands are stored in the file SYS:X29SRV.INI and can 
be changed at any time. However, X29SRV processes these commands only 
at startup time. While X29SRV is running, the characteristics remain 
static. 

There is, however, no need for the file SYS:X29SRV. INI to exist before 
X29SRV can function. X29SRV is designed to run and to interact with 
the remote PAD software using the CCITT X.3, X.28, and X.29 
recommendations. Thus, the system manager can choose to simply 
install the program and let it run without any intervention. 



D.1.1 Security Considerations 

The system manager can use the DEFINE commands to determine the degree 
of X29SRV's user-friendliness. An example of user-friendliness is the 
abundance of help text, prompts, and other system messages that guide 
the users in accessing systems successfully. This is particularly 
helpful to users who are not familiar with the installation and its 
access procedure. 

On the other hand, the system manager can choose not to provide these 
features to users who happen to connect to the PSI Gateway 
accidentally. The system manager may want to make it harder for those 
who are not familiar with the access procedure to gain access to any 
of the systems on the DECnet network. This can be done, for example, 
by having X29SRV disconnect the terminal after an unsuccessful attempt 
to connect to a system. 

These options are decided by the system managers. While there are no 
fool-proof ways of preventing illegal break-ins of systems over the 
Public Network, these options provide the system manager with a means 
to build the first line of defense against such practices. The 
responsibility of maintaining a system's security rests with the 
systems manager and the operating system. 



D.2 SAMPLE DIALOGUE 

The following sample of initialization set-up and dialogue illustrates 
the normal procedure for managing the TOPS-10 PSI X.29 software and 
using the software to access the TOPS-10 host. The system is assumed 
to be connected to the TELENET network. 
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D.2.1 X29SRV.INI 

The file SYS:X29SRV. INI, which contains the following commands, is 
created by the system manager to define the characteristics of X29SRV. 

DEFINE DEFAULT HOST DISABLED 

DEFINE HERALD Digital Equipment Corp. TOPS-10 PSI Gateway X.29 Server 

DEFINE MAXIMUM CIRCUITS 8 

DEFINE MAXIMUM CONNECT ERRORS 1 

DEFINE NETWORK TELENET 

DEFINE PROMPT "X29SRV> " 

DEFINE RESPONSE VERBOSE 

DEFINE REVERSE CHARGING ALLOWED 

DEFINE SET DEFAULT 1:1,2:1,3:126,4:10,5:1,6:1,7:1,8:0,9:0,10:0,12:1, - 

13:0,14:0,15:0,16:127,17:21,18:18,0:33,1:0,10:0, - 
18:0,27:127,28:21,29:18,37:1,57:1,63:0 

DEFINE SET FDX 1:1,2:0,3:0,4:1,5:1,6:1,7:1,8:0,9:0,10:0,12:0,13:4, - 
14:0,15:0,16:127,17:21,18:18,0:33,1:4,10:0,18:0, - 
27:127 28:21 29:18 37:1 
DEFINE SET HDX 1:1,2:1,3:6,4:0^5:1,6:1,7:1,8:0,9:0,10:0,12:1,13:0, - 

14:0,15:1,16:127,17:21,18:18,0:33,1:0,10:0,18:4,27:127, 
28:21,29:18,37:1 
DEFINE SET KERMIT 1:1,2:1,3:0,4:1,5:1,6:1,7:1,8:0,9:0,10:0,12:0,13:4, - 

14:0,15:0,16:127,17:21,18:18,0:33,1:4,10:0,18:0, - 
27:127,28:21,29:18,37:1,57:0,63:0 



D.2.2 Dialogue 

The following example shows the terminal session as seen by the user 
accessing the TOPS-10 system from a public access PAD on the TELENET 
network. 

TELENET 
617 181 

TERMINAL=D1 <RET> 

@C 61772 <RET> 

617 72 CONNECTED 

Digital Equipment Corporation TOPS-10 PSI Gateway X.29 Server 

Friday, April 13, 1984 11:06:31:AM VI. 0(0) #110(00) 

X29SRV> CONNECT KL1026 <RET> 

RL175D DEC10 Development 11:10:47 TTY52 system 1026/1042 
Connected to Node KL1026(26) Line # 52 
Please LOGIN or ATTACH 

.TTY NO ECHO 

.<BREAK> 

BREAK 

X29SRV> DISC <RET> 
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HOST SYSTEM DISCONNECTED 
X29SRV> CONNECT KS4145 FDX <RET> 
CSSE KS 4145 7.02 11:12:29 



[ Idle line disconnected by host ] 

HOST SYSTEM DISCONNECTED 
X29SRV> CLEAR <RET> 

DISCONNECTING 

617 72 DISCONNECTED 00 00 00:00:01:17 30 25 



D.3 MANAGEMENT COMMANDS 

The management commands can be used to define the characteristics of 
X29SRV. They are saved in the file SYS:X29SRV.INI. The commands are 
listed in alphabetical order in the following sections. 

All of these commands can be abbreviated. For example, "DEF D H E" 
can be used to represent the command DEFINE DEFAULT HOST ENABLED. A 
long command may be entered as several text lines as follows: 

DEFINE SET DEFAULT 1:1,2:1,3:126,4:10,5:1,6:1,7:1,8:0,9:0,10:0, - 

12:1,13:0,14:0,15:0,16:127,17:21,18:18, - 
0:0,1:0,10:0,18:0,27:127,28:21,29:18,37:1,57:1,63:0 

The character "-" (dash) at the end of the first two lines indicates 
to X29SRV that the command is continued on the next line. 



D.3.1 Error Conditions 

If you compose a command that is syntactically incorrect, X29SRV 
responds with the following error message at the console when it 
processes the SYS:X29SRV. INI file at startup time: 

Plllegal X29SRV command <text> 
<diagnostic> 

where <text> is the text string that X29SRV acknowledges reading from 
the SYS:X29SRV.INI file and <diagnostic> is the explanation why X29SRV 
thinks the command is incorrect. Following are samples of X29SRV 
detection of syntactical errors. For example, a misspelling of the 
parameter "HERALD" in the command line: 

DEFINE HERRALD Clark College Atlanta, Georgia 

may cause the following response: 

?Illegal X29SRV command "DEFINE HERRALD Clark College Atlanta, Georgia" 
Unrecognized switch or keyword: "HERRALD" 
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Too much of abbreviation in the command line (for example, "C" is 
intended to represent CIRCUITS in this command) : 

DEF MAX C 8 

may cause ambiguity as follows (There are two parameters that start 
with the character "C" — CIRCUITS and CONNECT ERRORS): 

?Illegal X29SRV command ."DEF MAX C 8" 
Ambiguous switch or keyword: "C" 



D.3.2 DEFINE DEFAULT HOST Command 

This command, if enabled, lets you automatically connect the X.29 
terminal to the TOPS-10 host system without specifying the CONNECT 
command. This may be desirable if the TOPS-10 PSI Gateway services 
only one TOPS-10 system. If your PSI Gateway node services more than 
one TOPS-10 host system, and this command is used, the X.29 terminal 
will be connected to the system that has X29SRV running. 

Syntax: 

DEFINE DEFAULT HOST control 
Arguments: 

control is one of the following: 

DISABLED 
ENABLED 

Messages: 

None 

Remarks : 

If control is ENABLED, the default X.3 parameter set will be used 
to define the terminal connection characteristics. 

Default control is DISABLED. 

Example: 

DEFINE DEFAULT HOST ENABLED 
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D.3.3 DEFINE HERALD Command 

This command defines the herald text to be displayed at the user's 
terminal at the beginning of the X.29 terminal session. 

Syntax: 

DEFINE HERALD text 



Arguments; 
text 



the herald text in the format of a list of octal 
representation of 8-bit bytes, quoted and unquoted 
strings of up to 2047 characters in length. An 
unquoted string is only allowed to be the last 
element of the list, and it must be terminated by 
a carriage return. 



Messages; 

None 

Remarks: 

X29SRV automatically adds a pair of carriage return and line feed 
characters at the end of the herald text string if none are 
there. 

Default is no herald text. 

Example: 

DEFINE HERALD 15 , 12 , "Digital Equipment Corporation ETC, Valbonne" ,15,12 
DEFINE HERALD Clark College, Atlanta Georgia 



D.3.4 DEFINE MAXIMUM CIRCUITS Command 

This command defines the maximum number of simultaneously active X.29 
terminal connections serviced by X29SRV. 

Syntax: 

DEFINE MAXIMUM CIRCUITS count 
Arguments: 

count number of circuits range from 1 to 20. 

Messages: 

NUMBER OF MAXIMUM CIRCUITS EXCEEDED LIMIT 

The specified number of maximum circuits that can 
be active simultaneously exceeded 20. 

Remarks: 

Default is 8. 
Example: 

DEFINE MAXIMUM CIRCUITS 16 
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D.3.5 DEFINE MAXIMUM CONNECT ERRORS Command 

This command sets the limit of the allowed number of unsuccessful 
attempts to connect to a host system on the DECnet network before the 
connection between the PAD and the TOPS-10 PSI Gateway is terminated. 

Syntax : 

DEFINE MAXIMUM CONNECT ERRORS count 
Arguments ; 

count number of attempts allowed. 

Messages: 

None 
Remarks : 

Default is 1. 
Example: 

DEFINE MAXIMUM CONNECT ERRORS 3 



D.3.6 DEFINE NETWORK Command 

This command notifies X29SRV of the PPSN that the TOPS-10 PSI Gateway 
software is connected to. This command is necessary only when the 
PPSN that your system is connected to does not provide the full 
implementation of CCITT X,3, X,28 and X.29 interface. 



Syntax : 



DEFINE NETWORK name 

NETWORK CLASS number 



Arguments : 
name 



is the name of the PPSN. 
following PPSN names: 



X29SRV recognizes the 



DATEX-P 
PSS 

TELENET 
TRANS PAC 
TYMNET 



Federal Republic of Germany 

The United Kingdom 

The United States 

France 

The United States 
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number 



The class of the PPSN, Some of the leading PPSN 
vendors market their network software and 
technology to other PPSN vendors. The network 
class identification is a means used by X29SRV to 
classify similar PPSNs with those it is familiar 
with. 



Class 


Network 


Country 





DATAPAK 


Norway 




TELENET 


The United States 


1 


TRANS PAC 


France 


2 


DATEX-P 


Federal Republic of 
Germany 


3 


DATANET-1 


The Netherlands 




PSS 


The United Kingdom 


4 


TYMNET 


The United States 



Messages: 

UNKNOWN NETWORK CLASS 



The specified Network Class number is not 
recognized by X29SRV. 



Remarks: 



If your PPSN name is not on the above network name list, contact 
your DIGITAL software specialist for your PPSN's network class. 



Example: 



DEFINE NETWORK DATEX-P 
DEFINE NETWORK CLASS 4 



D.3.7 DEFINE PROMPT Command 

This command lets you define the prompt text string that is displayed 
at the user's terminal in X29SRV's Command Mode when it is ready to 
receive user's commands. 

Syntax: 

DEFINE PROMPT text 



Arguments 
text 



the prompt text in the format of a list of octal 
representation of 8-bit bytes, quoted and unquoted 
strings of up to 127 characters in length. An 
unquoted string is allowed only to be the last 
element of the list, and it must be terminated by 
a carriage return. 



Messages : 

None 
Remarks : 

Default is no prompt. 
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Examples 



DEFINE PROMPT 15, 12 , "Please , enter CONNECT host" ,15, 12, 12 
DEFINE PROMPT X29SRV> 



D.3.8 DEFINE RESPONSE Command 

This command determines the verbosity of X29SRV while servicing the 
remote terminals. 

Syntax : 

DEFINE RESPONSE control 
Arguments: 

control is one of the following: 

QUIET 
VERBOSE 

Messages: 

None 
Remarks: 

Default is QUIET. 
Example: 

DEFINE RESPONSE VERBOSE 

D.3.9 DEFINE REVERSE CHARGING Command 

This command allows X29SRV to accept incoming calls with the reverse 
charge facility (such as calls that originate from public PAD 
facilities of the PPSN) . Otherwise, those incoming calls are 
rejected. 

Syntax: 

DEFINE REVERSE CHARGING control 
Arguments: 

control is one of the following: 

ALLOWED 
DISALLOWED 

Messages; 

None 
Remarks : 

Default is ALLOWED. 
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Example: 

DEFINE REVERSE CHARGING DISALLOWED 

D.3.10 DEFINE SET Command 

This command defines various sets of CCITT and national X,3 parameters 
to be requested by the users to define the characteristics of their 
terminal connections. The maximum number of X.3 parameter sets that 
can be defined is 18 (including the default parameter set DEFAULT). 
See Section D.4 for a description of the CCITT X.3 parameters. 



Syntax: 



DEFINE SET DEFAULT list 
name list 

Arguments: 

name is the text string representing the name of the 

X.3 parameter set of up to 6 characters in length. 

list is the list of the CCITT and national X.3 

parameters to be defined in the set. The list has 
the following format: 

parameter : value [, parameter : value] 

where parameter is the X.3 parameter number ranges 
from 1 to 127 and value is the associated X.3 
parameter value. All values are in decimal. 
X29SRV will not attempt to validate the X.3 
parameter values. The values however must not be 
greater than 255 decimal. 

Messages: 

NUMBER OF X.3 PARAMETER SETS EXCEEDED LIMIT 

You have defined more than 17 X.3 parameter sets. 

DUPLICATED NATIONAL X.3 PARAMETER DEFINITION 

You have specified more than one national X.3 
parameter separator (see remarks below) in the 
list of X.3 parameters. 

X.3 PARAMETER NUMBER IS OUT OF RANGE 

The value of an X.3 parameter number is outside 
the range of 1 to 127 decimal. 

X.3 PARAMETER VALUE OCCUPIES MORE THAN ONE OCTET 

The value of an X.3 parameter value is greater 
than 255 decimal. 
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Remarks : 

The reserved X.3 parameter set name is DEFAULT, which is the 
default X.3 parameter set. 

When you specify the list of X.3 parameters, you can include the 
national X.3 parameters in the list by preceding them with the 
X.3 separator 0:0. The national X.3 parameter numbers may range 
from 1 to 127. The number of defined national X.3 parameters in 
each set should not exceed 45. X29SRV will not attempt to 
validate the X.3 parameter values. However, the values must not 
be greater than 255 decimal. 

If X29SRV encounters errors while processing the parameter 
definitions, the entire X.3 parameter set is discarded and the 
set name will be undefined. 

Example: 

DEFINE SET DEFAULT 1:1,2:0,3:0,4:1,5:1,9:0,11:2,15:1,16:127,17:21,18:18 
DEFINE SET EMACS 0:0,57:1,63:0 
DEFINE SET VMS 3:2,4:0,0:0,57:1,63:0 
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D,4 VALUES OF THE PAD PARAMETERS 

This appendix assumes that your network suppots PADs that conform to 
the CCITT X,3 Recommendation of 1980. Table D-1 provides a summary of 
the PAD parameter values. 



Table D-1: Summary of PAD Parameter Values 



Parameter 
Number 


Values 


1 


0, 1 

32-126 (optional) 


2 


0,1 


3 


0, 2, 126 

6, 18 (optional) 


4 


0, 20, 255 

1-19, 21-254 (optional) 


5 


0, 1 


6 


0, 1 


7 


0, 2, 8, 21 
1 (optional) 


8 


0, 1 


9 


0-7 


10 


0, 1-255 


11 


0, 2, 8 

1, 2, 4-7, 9-18 (optional) 


12 


0, 1 


13 


0, 1, 4, 5, 6, 7 


14 


0-7 


15 


0, 1 


16 


0-127 


17 


24 

0-23, 25-127 (optional) 


18 


0-127 
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D.4.1 Parameter 1 - PAD Recall Using a Character 

This parameter controls the action of the PAD on receipt of a DLE 
(<CTRL/P>) from the terminal, when the PAD is in the Data Transfer 
state. The parameter values are: 

No escape from the Data Transfer state allowed, 
except with break signal (see parameter 7) 

1 Escape from the Data Transfer state to the Waiting 
for Command state occurs when a DLE is received from 
the terminal 

32-126 Escape from the Data Transfer state to the Waiting 
for Command state occurs when the graphic character 
specified by the ASCII code (decimal) given here is 
received 

The preferred value of this parameter for an X.29 terminal is 1; 
this allows interaction with the PAD (for example, to read the 
values of PAD parameters) . 



D.4.2 Parameter 2 - Echo 

This parameter determines whether the PAD echoes characters received 
from the terminal. The parameter values are: 

The PAD does not echo. 

1 The PAD echoes, except when buffer space limitations 
cause it to ignore a character from the terminal. 



D.4,3 Parameter 3 - Selection of Data Forwarding Signals 

This parameter defines which characters (received from the terminal) 
cause the PAD to forward the current packet to the host DECsystem-10 
computer. The parameter values are: 



2 

6 

18 

126 
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These values are a combination of one or more of the following: 

Forwarding on receipt of the 129th character 

1 Alphanumerics, that is, A-Z, a-z, and 0-9 

2 <RET> 

4 <ESC>, <BEL>, <ENQ>, and <ACK> 

8 <DEL>, <CAN>, and <DC2> 

16 <ETX> and <EOT> 

32 <HT>, <LF>, <VT>, <FF> 

64 All other control characters not in the above list. 

The value 6 is the combination of 2+4, 18 is the combination of 
2+16, and 126 is the combination of 2+4+8+16+32+64. 

The PAD never transmits empty data packets. The PAD normally 
includes the forwarding character in the packet it causes to be 
forwarded. If the packet is full, the PAD includes the forwarding 
character in the next packet. 

D.4.4 Parameter 4 - Selection of Idle Timer Delay 

This parameter controls whether there is data-forwarding timeout 
and, if so, its length. The parameter values are: 

No data forwarding timeout 

20 Data forwarding timeout of 1 second 

255 Data forwarding timeout of 12.75 seconds 

1-19,21-254 The data forwarding timeout length in units of 
1/20 second 

D.4.5 Parameter 5 - Ancillary Device Control 

This parameter enables or disables ancillary device control of the 
terminal by the PAD. The parameter values are: 

No ancillary device control 

1 Ancillary device control (the PAD transmits X-ON and 
X-OFF to the terminal) 
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D.4.6 Parameter 6 - Control of PAD Service Signals 

This parameter determines whether PAD service signals are suppressed 
or transmitted to the terminal. The parameter values are: 

PAD service signals suppressed 

1 PAD service signals transmitted to your terminal 

5 PAD service signals and the prompt PAD service signal 
transmitted to the terminal 



D,4.7 Parameter 7 - Action of PAD on Receipt of Break Signal 

This parameter specifies the action to be taken by the PAD on 
receipt of a BREAK signal from the terminal. The parameter values 
are: 



1 

2 

8 

21 

These values are a combination of one or more of the following: 

No action or receipt of <BREAK> 

1 The PAD sends an interrupt to the TOPS-10 system 

2 The PAD sends a reset to the TOPS-10 system 

4 The PAD sends an Indication Break PAD message to the 
TOPS-10 system 

8 The PAD leaves the Data Transfer state and enters the 
Waiting for Command state 

16 The PAD discards output to the terminal by setting 
parameter 8 to the value 1 

where 21 is a combination of 1+4+16. 



D.4,8 Parameter 8 - Discard Output 

This parameter specifies that the PAD delivers data to the terminal. 
The parameter values are: 

Normal data delivery 

1 No data delivery to the terminal; the PAD discards 
any data received from the host computer 
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D.4,9 Parameter 9 - Padding After Carriage Return 

This parameter specifies the number of padding characters after a 
<RET>, The parameter values are: 

No padding after <RET> 

1-7 One to seven padding characters inserted after <RET> 



D.4.10 Parameter 10 - Line Folding 

This parameter specifies whether or not line folding is to be 
performed, and, if so, it specifies the maximum length of the line. 
The parameter values are; 

No line folding performed 

1-225 Enables line folding and specifies the maximum line 
length for all data transmitted or echoed by the PAD 
to the terminal 



D,4.11 Parameter 11 - Speed of Start-Stop Mode Terminal 

This parameter specifies the receive-transmit speed of the user 
terminal. The parameter values are: 






110 


bits/s 


1 


134.5 


bits/s 


2 


300 


bits/s 


3 


1200 


bits/s 


4 


600 


bits/s 


5 


75 


bits/s 


6 


150 


bits/s 


7 


1800 


bits/s 


8 


200 


bits/s 


9 


100 


bits/s 


10 


50 


bits/s 


11 


75/1200 


bits/s 


12 


2400 


bits/s 


13 


4800 


bits/s 


14 


9600 


bits/s 


15 


19200 


bits/s 


16 


48000 


bits/s 


17 


56000 


bits/s 


18 


64000 


bits/s 



Note that the support of any of these values depends on the 
supported data transmission rates of the PAD. 

Neither the terminal nor the host computer can set parameter 11. 
The PAD sets this parameter by detecting the line rate from the 
Service Request sequence from the terminal. 
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D.4.12 Parameter 12 - Flow Control of the PAD 

This parameter enables or disables flow control of data between the 
PAD and the terminal. The parameter values are: 

No flow control on 

1 Flow control on (that is, the PAD responds to X-ON 
(<CRTL/Q>) and X-OFF (<CRTL/S>) transmitted by the 
terminal) . 



D.4.13 Parameter 13 - Line Feed Insertion After Carriage Return 

This parameter controls <LF> insertion after <RET>. The parameter 
values are: 

No <LF> insertion 

1 <LF> inserted after every <RET> transmitted (but not 
echoed) to the terminal 

4 <LF> inserted after every <RET> echoed to the 
terminal 

5 <LF> inserted after every <RET> transmitted and 
echoed to the terminal 

6 <LF> inserted after every <RET> echoed to the 
terminal and transmitted to the host computer 

7 <LF> inserted after every <RET> transmitted to your 
terminal, echoed to the terminal, and transmitted to 
the host computer 



D,4,14 Parameter 14 - Padding After Line Feed 

This parameter specifies the number of padding characters after a 
<LF>. The parameter values are: 

No padding after <LF> 

1-7 One to seven padding characters inserted after a <LF> 



D.4.15 Parameter 15 - Editing 

This parameter determines whether buffer editing is available while 
in the Data Transfer state. The parameter values are: 

No editing in the Data Transfer state 

1 Editing in conjunction with parameters 16, 17 and 18. 
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D.4.16 Parameter 16 - Character Delete 

This parameter specifies if character deleting in the Data Transfer 
state is enabled and, if so, it specifies the character delete 
character. The parameter values are: 

No character delete in the Data Transfer state 

1-127 The decimal code of the character chosen as the 
Character Delete character 



D.4.17 Parameter 17 - Line Delete 

This parameter specifies if line (or buffer) deleting in the Data 
Transfer state is enabled and, is so, it specifies the line delete 
character. The parameter values are: 

No buffer delete in the Data Transfer state 

1-127 The decimal code of the character chosen to be the 
Buffer Delete character 

If parameter 4 (data forwarding timeout) is set to a low value, the 
PAD will forward the data before you have time to edit it. 



D.4.18 Parameter 18 - Line Display 

This parameter specifies if line displaying is enabled and, if so, 
specifies the Line Display Character. The parameter values are: 

1-127 The decimal code of the character chosen to be the 
line display character 
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APPENDIX E 
BIBLIOGRAPHY 



The following DIGITAL documents contain detailed information on the 
protocols used in DECnet. The appendix section of the Overview of 
Digital Networking Products contains a complete list of DECnet 
manuals as well as manuals pertinent to DECnet, such as Ethernet and 
PSI. 

Each of the following subtitles is preceded by "DECnet DIGITAL 
Network Architecture" and followed by "Functional Specification" or 
(for DDCMP) "Specification" (except for Introduction to DECnet) . 

Introduction to DECnet 

General Description 

This is an overview of the architecture and 
provides an introduction to each of the 
following documents. 

Data Access Protocol (DAP) 

Digital Data Communications Message Protocol (DDCMP) 

Maintenance Operation Protocol (MOP) 

Network Management Protocol 

Network Services Protocol (NSP) 

Routing 

Session Control 

The following lists CCITT recommendations relevant to users of the 
TOPS-10 PSI software and the CCITT publications in which those 
recommendations are discussed. For more information, contact the 
CCITT. 
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Recommendation 

X.3 

X.25 

X,28, X.29 



Document 

Document AP VII-No. 6-E 

Document AP VII-No. 7 

Document AP VII-No. 8 



The following document contains a complete and unabridged form of the 
key CCITT recommendations as they appear in the Fascile VIII. 2 of the 
Yellow Book of the Consultative Committee for International Telegraph 
and Telephone, 1981 edition. 

The X.25 Protocol and Seven Other Key CCITT Recommendations X.l, 
X.2, X.3, X.21 bis, X.28, and X.29. Lifetime Learing 
Publications, Belmont, California, 1981 

The following published books are a source of general network 
information. The list is both arbitrary and abbreviated and is 
intended to be a catalyst to stimulate the reader's interest. 



Title Author 

Application Design Handbook Patrick, 

for Distributed Systems Robert L, 

Basics of Data Communication Karp, ed. 

Communications Networks for Davies and 

Computers Barker 

Computer Networks and Martin, 

Distributed Processing: James 
Software, Techniques, 
and Architecture 

Data Communications Doll 

Design and Strategy Martin, 

for Distributed Data James 
Processing 

Handbook of Data Editors 
Communications 



Introduction to Data Murphy and 

Communications Kalis 



Introduction to Mini- 
Computer Networks 

Introduction to 
Teleprocessing 

Technical Aspects of Data 
Communication 



Martin, 
James 

McNamara, 
John E. 



Publisher 
CBI Publishing Co. 

McGraw-Hill 
Wiley and Sons 

Prentice-Hall 

Wiley Interscience 
Prentice-Hall 



National Computing 
Centre Publications 
(United Kingdom) 

DIGITAL 



DIGITAL 

Prentice-Hall 

DIGITAL 
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DECnet LINE DEVICES 



Table F-1: DECnet Line Devices 



Mnemonic 


Multi- 
line 


Multi- 
point 


DECnet-10 
Support 


TOPS-10 PSI 
Support 


Description 


CI 


No 


Yes 


No 


No 


CI20 Computer 
interconnect 


DA 


No 


No 


No 


No 


DAll-B or 
DAll-AL UNIBUS 
link 


DL 


No 


No 


No 


No 


DLll-C, 

DLll-WA, and 
DLll-E 

asynchronous 
line interface 


DLV 


No 


No 


No 


No 


DLVll-E 
asynchronous 
line interface 
(11/03 and 
11/23 only) 


DMC 


No 


No 


Yes (MCB) 


No 


DMCll-DA/AR, 

DMCll-MA/AL, 

DMCll-MD/AL, 

DMCll-FA/AR 

interprocessor 

links 


DMR 


No 


No 


Yes (MCB) 


No 


DMRll-AA, 

DMRll-AB, 

DMR 11 -AC, 

DMRll-AE 

interprocessor 

links 


DMF 


No 


No 


No 


No 


DMF-32 
synchronous 
line unit 
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Table F-1; DECnet Line Devices (Cont.) 



Mnemonic 


Multi- 
line 


Multi- 
point 


DECnet-10 
Support 


TOPS-10 PSI 
Support 


Description 


DMP 


No 


Yes 


No 


No 


DMP-11 
multipoint 
synchronous 
line device 


DP 


No 


No 


No 


No 


DP 11 -DA 
synchronous 
line interface 


DPV 


No 


No 


No 


No 


DPVll-DA 
synchronous 
line interface 


DQ 


No 


No 


No 


No 


DQll-DA 
synchronous 
serial line 
interface 


DTE 


No 


No 


Yes 


Yes 


DTE 20 

interprocessor 

link 


DU 


No 


No 


No 


No 


DUll-DA 
synchronous 
line interface 
( includes 
DUVll) 


DUP 


No 


No 


Yes (MCB) 


No 


DUP-llDA 
synchronous 
line interface 


DV 


Yes 


No 


No 


No 


DVll-AA/BA NPR 
synchronous 
line 
multiplexer 


ETH 


No 


Yes 


Yes 


No 


NIA20 

multiaccess 
communications 
link 


KDP 


Yes 


No 


Yes 


Yes 


KMC-11/DUP-ll-DA 
NPR synchronous 
line 
multiplexer 
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Table F-li DECnet Line Devices (Cent.) 



Mnemonic 


Multi- 
line 


Multi- 
point 


DECnet-10 
Support 


TOPS-10 PSI 
Support 


Description 


KDZ 


Yes 


No 


No 


No 


KMC-11/DZll 
-A/B/C/D NPR 
asynchronous 
line 
multiplexer 


KL 


No 


No 


No 


No 


KL8-J serial 
line interface 


KMV 


Yes 


No 


No 


No 


KMSll-BD/BE 
synchronous 
line interface 
combined with 
X.25 level 2 
microcode 


KMX 


Yes 


No 


No 


No 


KMSll-BD/BE 
synchronous 
line interface 
combined with 
X.25 level 2 
microcode 


KMY 


No 


No 


No 


No 


KMSll-PX 
synchronous 
line interface 
combined with 
X.25 level 2 
raircrocode 


PCL 


No 


Yes 


No 


No 


PCLll-B 

multiple CPU 
link 


QNA 


No 


Yes 


No 


No 


DEQNA 

multiaccess 
communications 
link 


TT 


Yes 


No 


No 


No 


DZll-F, DZ32-F, 
or DZVll-D 
asynchronous 
serial line 
multiplexer 


TX 


No 


No 


No 


No 


DMF-32/DMZ-32 
asynchronous 
line unit 



F-3 



DECnet LINE DEVICES 



Table F-1: DECnet Line Devices (Cont.) 



Mnemonic 


Multi- 
line 


Multi- 
point 


DECnet-10 
Support 


TOPS-10 PSI 
Support 


Description 


NI 


No 


Yes 


No 


No 


NIA20 

multiaccess 
communications 
link 
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GLOSSARY 



The definitions and explanations in this glossary are specific to 
their use in this manual. 

Active A designation for plural entities that 

limits them to those that meet an 
activity criterion. The criterion is 
defiaed individually for each entity. 

Active lines Known lines in the ON or SERVICE state. 

Active logging All known sink types that are in the ON 

or HOLD state. 

Active nodes All reachable nodes as perceived from 

the executor node. 

Adjacent node A node connected to the executor node by 

a single physical line. 

Aged packet A packet that has exceeded the maximum 

number of visits. 

Area A group of nodes in a network that can 

run independently as a subnetwork. 

Area router A level 2 router. 

Area routing A technique for grouping the nodes in a 

network into areas for routing purposes. 
Routing in a multiple-area network is 
hierarchical, with one level of routing 
within an area (called level 1 routing) 
and a second, higher level of routing 
between areas (called level 2 routing) . 

Bilateral Closed User Group (BCUG) 

An optional PPSN facility that restricts 
a pair of DTEs to communicating with 
each other. The basic BCUG also 
prevents this pair from accessing or 
being accessed by other DTEs. Additions 
to the BCUG facility allow one or both 
of the DTEs to access or be accessed by 
DTEs outside the group. These additions 
are known as BCUG with Outgoing Access 
and BCUG with Incoming Access 
respectively. See also related Closed 
User Group. 
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Broadcast addressing 



Broadcast circuit 



CCITT 



Central Management Node 



Characteristics 



Circuit 



A special type of multicast addressing, 
in which a message is sent to all nodes, 

A circuit on which multiple nodes are 
connected and on which there is a method 
for transmitting a message that will be 
received by multiple receivers, 

Comite Consultatif International 
Telegraphique et Telephonique, An 
international consultative committee 
that sets international communications 
usage standards. 

Any node that is capable of parsing all 
DNA NOP commands, including those that 
the central management node cannot or 
does not implement for its operating 
system. A central management node is 
capable of managing the entire network 
of which it is a member; it can set 
parameters and initiate and terminate 
the operation of nodes, circuits, lines, 
and events and alter the logical 
configuration of the network. 

Parameters that are generally static 
values in volatile memory or permanent 
values in a permanent data base. A 
Network Management information type. 
Characteristics can be set or defined. 
Examples of characteristics are the 
values assigned in response to the 
keywords NAME, TYPE, and LOAD FILE. 

A logical point-to-point connection. A 
circuit is identified by device, 
controller, unit, and (if present) 
tributary. For example, KDP-2-0,1, 



Closed User Group (CUG) 



An optional PPSN facili 
two or more DTEs in 
communicating with ea 
basic CUG also prevent 
accessing or being ac 
DTEs outside the gro 
the basic CUG facility 
DTEs to access or be 
outside the group. The 
known as CUG with Ou 
CUG with Incoming Acces 



ty that restricts 
the same group to 
ch other. The 
s these DTEs from 
cessed by other 
up. Additions to 
allow one or more 
accessed by DTEs 
se additions are 
tgoing Access and 
s respectively. 



Command node 
Controller 



The node where 
originates. 



an 



NCP 



command 



That part of a line identification that 
denotes the control hardware for a line. 
For a multiplex device, that controller 
is responsible for one or more units. 
For example, in the line identification 
KDP-0-1, the controller is KMC-0. (The 
KDP is a KMC controller with up to four 
DUPs.) 
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Cost 



Counters 



Datagram 



Data Link 



Data Transmission 



DCE 



An integer value assigned to a circuit 
between two adjacent nodes. According 
to the routing algorithm, packets are 
routed on paths with the lowest cost. 

Error and performance statistics based 
on a node's network activity. 

A unit of data sent over the network 
that is handled independently of all 
other units of data so far as the 
network is concerned. When a route 
header is added, a datagram becomes a 
packet. 

A physical connection between two nodes. 
In the case of a multipoint line, there 
can be multiple data links for one 
physical connection. 

The sending of data from one computer to 
another over a physical link, or from 
one task to another over a logical link. 

Data Communications Equipment (DCE) is 
an X.25 PPSN node to which a DTE is 
connected with a leased data 
communications line. 



DDCMP 



Designated router 



DIGITAL Data Communications Message 
Protocol. A formal set of conventions 
designed to provide error-free, 
sequential transmission of data over 
physical links. 

A routing node on the Ethernet selected 
to perform routing services on behalf of 
end nodes. 



DMCll 



A single line microprocessor-based 
interface to the network. The DMCll is 
a synchronous Direct Memory Access (DMA) 
device. 



DMRll 



A single line microprocessor-based 
interface to the network. The DMRll is 
a synchronous Direct Memory Access (DMA) 
device. 



DN20 

Downline Loading 

DTE 



The DECnet-10 communication front end. 

Transmitting a program's memory image 
over a physical link to an adjacent node 
and starting execution of it. 

Data Terminal Equipment (DTE) is a host 
processor or communications processor 
directly connected to an X,25 PPSN with 
a leased data communications line. 



DTE20 



The hardware interface between the main 
processor in a DECsystem-1090/10911095 
and the PDP-11 processor in the DN20 
communication front end. 
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End node 



Entity 



A node that can receive packets 
addressed to it and send packets to 
other nodes, but cannot route packets 
through from other nodes. Also called a 
nonrouting node. 

AREA, CIRCUIT, LINE, LOGGING, MODULE, or 
NODE. These are t*he major Network 
Management keywords. Each entity has 
its own parameters and options. 
CIRCUIT, LINE, and NODE have counters 
also. Allowed plural forms are KNOWN 
and ACTIVE AREAS, CIRCUITS, LINES, 
MODULES and NODES. NODES can also take 
the form LOOP NODES. Entities are 
components that can be displayed and 
controlled. 



Ethernet 



Ethernet protocol 



A communications concept for local 
communication networks, which employ 
coaxial cable as a passive 
communications medium to interconnect 
different kinds of computers, without 
requiring switching logic or control by 
a central computer 

In the data-link layer of DNA (DIGITAL 
Network Architecture) , the protocol that 
implements the Ethernet data-link 
protocol for communication between 
adjacent nodes connected by an Ethernet 
local area network. 



Event 



A network- or system-specific occurrence 
for which the logging entity maintains a 
record , 



Event Class 



Event Filter 



A subset of events, currently consisting 
of groups of events associated with each 
of the DNA layers or with specific 
operating systems. 

A set of on/off states for a logging 
event class that indicates whether or 
not each event type in that class is to 
be recorded. 



Event Type 
Executor Node 



Frame 



A particular type of event, 
within an event class. 



unique 



The node where the active Local Network 
Management Function is running (that is, 
the node actually executing the 
command); the active network node 
physically connected to one end of a 
line being used for a load, dump, 
trigger, or line loop test, 

A unit, delimited by flags, that 
includes a header used by the link level 
to exchange data packets as well as 
control and error information between 
the DTE and DCE. 
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Full-duplex 



Simultaneous independent transmission in 
both directions. 



Full Routing Node 



A node that allows communication between 
non-adjacent nodes. If all nodes in a 
network are full routing nodes, then 
each node can communicate with every 
other node in the network. 



Global Filter 



Half-duplex 



Hardware address 



Hold State 



Hop 



Host Computer 



A filter that applies to all entities 
within an event class and type. 

Transmission in either direction, but 
not in both directions simultaneously. 

For an Ethernet device, the unique 
Ethernet physical address associated 
with a particular Ethernet 
communications controller (usually in 
read-only memory) by the manufacturer. 

A logging state in which the sink is 
temporarily unavailable and events for 
it should be queued. 

A hop is one unit of path length. When 
a request is routed from node A to node 
C by way of Node B, two hops are 
involved: node A to node B is one hop; 
node B to node C is another hop. (See 
path cost.) 

A computer at a network node that 
primarily provides services such as 
computation, data base access, special 
programs, or programming languages to 
other nodes in the network. 



Host Node or Host 



The node that provides services for 
another node (for example, the storage 
of files needed for a downline load). 



Information Type 



One of CHARACTERISTICS, COUNTERS, 
EVENTS, or SUMMARY. Used with the NCP 
SHOW command to control the type of 
information returned. Each entity 
parameter and counter is associated with 
one or more information types. 



KDP 



KNOWN 



A DECnet terra that refers to a 
combination of a KMCll (controller) and 
one to four DUPlls. With the KMCll, a 
microprocessor-based system, the DUPll 
functions as a direct memory access 
device. The interface to the network is 
synchronous. 

The classification for a plural entity 
that includes all perceived occurrences 
of the entity type. 
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KNOWN LINES 



Level 1 router 



Level 2 router 



Line 
Line Cost 



Line Identification 
Line Level Loopback 

Load 

Local DTE 
Local Node 



Local User 



All lines addressable by Network 
Management in the appropriate data base 
(volatile or permanent) on the executor 
node. They may not all be in a usable 
state. 

A node that can send and receive 
packets, and route packets from one node 
to another, only within a single area, 

A node that can send and receive 
packets, and route packets from one node 
to another, within its own area and 
between areas. Also known as an area 
router , 



A distinct physical data path, 
a Network Management entity. 



Line is 



An arbitrary positive integer value 
assigned to a physical path. Because 
the routing algorithm selects the 
least-cost path to a destination, an 
operator can dynamically affect the path 
to be taken by changing line costs. 

The device, controller, unit and/or 
tributary assigned to a line. Examples 
are KDP-0-1, DMC-1. 

Testing a specific data link by sending 
a repeated message directly to the data 
link layer and over a wire to a device 
that returns the message to the source. 

To read data into memory. 



The communications node that connects to 
the public network. 

From the user's standpoint, a relative 
term indicating the node at which your 
terminal is logged in. From Network 
Management's standpoint, the node at 
which your requested task executes. If 
at your local node you SET the executor 
to another node, that other node is the 
local node to Network Management and the 
node where your terminal is attached is 
a remote node. 

A user of the User Acess Module who 
communicates with the public network 
through the node running TOPS-10 PSI 
Gateway Software. Also called user. 
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Logging 



Logging Console 



Logging Event Type 



Recording information from an occurrence 
that has potential significance in the 
operation and/or maintenance of the 
network in a potentially permanent form. 
Logging is the Network Management entity 
that routes event data to logging sinks 
such as a console or file. Logging 
sinks can be accessed by persons and/or 
programs. 

A logging sink that is to receive a 
human-readable record of events, for 
example, a terminal or printer. 

The identification of a particular type 
of event, for example, a line restarted 
or a node down. 



Logging File 



A logging sink that is to receive a 
machine-readable record of events for 
later retrieval. 



Logging Identification 



Logging Monitor 



The sink type associated with the 
logging entity (file, console, or 
monitor) . 

A logging sink that is to receive a 
machine-readable record of events for 
possible real-time decision making. 
Typically, the logging monitor is a 
user-defined program. 



Logging Sink 



A place where a copy of an event is 
be recorded. 



to 



Logging Sink Flags 



A set of flags in an event record that 
indicate the sinks on which the event is 
to be recorded. 



Logging Sink Node 



A node to which logging information 
comes . 



Logging Source Process 
Logical Connectivity 



The process that recognized an event. 

The ability of nodes to communicate with 
each other. 



Logical Link 



Loopback 



A node-to-node connection that is 

established and controlled by the 

Session Control, Network Services, and 
Routing layers, 

A mode of operation in which data 
transmitted by a network task is 
reflected at some point along the 
communication path and returned to the 
originating task. 
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Loopback Node 



Maximum Cost 



Maximum Hops 



Maximum Visits 



Maximum Node Address 
Maximum Path Cost 

Nodule 

Multiaccess Channel 

Multicast Addressing 

Multicast Group Address 

Multipoint Line 
Monitor Slnktype 

Network diameter 



A special name for a node that is 
associated with a line for loopback 
testing purposes. The SET NODE CIRCUIT 
command sets the loopback node name. A 
loopback node is treated as if it were a 
remote node. All traffic to the 
loopback node is looped over the 
associated line. 

The greatest total cost the path to a 
node may have if the node is to be 
reachable. When the cost associated 
with transmitting a message from one 
node to another exceeds the maximum 
cost, the transmission is not made. 

The maximum number of hops a path to a 
node can contain if the node is to be 
reachable. Currently, the maximum hops 
supported is 30. 

The maximum number of nodes a message 
coming into this node can have visited. 
If the number specified as MAXIMUM 
VISITS is exceeded, and the destination 
is not this node, then the message is 
discarded. 

The largest node address with which the 
local node can communicate. 

The greatest value assigned to the 
least-cost path between any two nodes in 
the network. 

A network management component. 

A medium (for example, Ethernet) on 
which many transmitters contend for 
access. 

An addressing mode in which a given 
message packet is targeted to a group of 
logically related nodes. 

An address assigned to a number of nodes 
on an Ethernet and used to send a 
message to all nodes in the group in a 
single transmission. 

A line connected to more than two nodes. 

An event sink that is to receive a 
machine-readable record of events for 
possible real-time decision making. 

The reachability distance between the 
two nodes on the network having the 
greatest reachability distance. 
Reachability distance is the length of 
the shortest path between a given pair 
of nodes. 
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Network Interconnect (NI) 



A multiaccess interconnect that allows 
up to 1024 different stations to 
communicate over the Ethernet, 



Network Services Protocol 

(NSP) 



Node 



Node Address 



Node Identification 



Node Level Loopback 



Node Name 



Nonrouting Node 



Off State 



A formal set of conventions used in 
DECnet to exchange messages over logical 
links. NSP also refers to the program 
that implements the NSP protocol. (In 
the text of this manual, NSP refers to 
the program; NSP Protocol is used to 
refer to the protocol.) This protocol is 
implemented by the End Communications 
Layer of the DNA architecture. 

An computer system that supports DECnet. 
Used alone in this manual, node implies 
support of Routing, NSP, and Session 
Control. A node that does not support 
these three layers is called a Phase II 
node. Node is a Network Management 
entity. 

The required unique numeric 
identification of a specific node. 

Either a node name or a node address. 
In some cases, an address must be the 
node identification. In other cases, a 
name must be used. DECnet contains a 
table for converting one to the other. 

Testing a logical link using repeated 
messages that flow with normal traffic 
through the Session Control, Network 
Services, and Routing layers within one 
node or from one node to another and 
back. In some cases node level loopback 
involves using a loopback node name 
associated with a particular line. 

An alphanumeric identification 
associated with a node address in a 
strict one-to-one mapping. The node 
name must contain at least one letter 
and cannot be more than six characters 
long. 

An end node. It can deliver and receive 
packets, but cannot route messages 
through to other nodes. 

Applied to a node: a state where 
network traffic is no longer processing. 
Applied to a line: a state where the 
line is unavailable for any kind of 
traffic. Applied to logging: a state 
where the sink is not available for 
receiving events; in this state any 
events for the sink are discarded. 
Applied to circuits: the state where 
the circuit is not in use by any 
network-related software. 
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On State 



Applied to a node: a state of normal 
network operation. Applied to a line: 
a state of availability for normal 
usage. Applied to logging: a state 
where a sink is available for receiving 
events. 



OPR 



Originating Packet 



ORION 



Packet 



OPR is the Operator Command Language 
program that provides the operator with 
one command language to communicate with 
several TOPS-10 components. OPR 
processes commands for syntax and passes 
syntactically correct commands to ORION. 
(See ORION.) 

A packet that originated in the Network 
Services layer of a node. 

ORION is the operator control program 
that accepts commands from OPR and 
forwards the commands to the proper 
program for execution. ORION forwards 
NCP commands to the Network Control 
Program. 

A group of bits, comprising data and 
control information, which is 
transmitted as a composite whole over a 
physical link. The data, control, and 
any error information are arranged in a 
specific format. (A packet is the basic 
transmission unit of DDCMP.) 



Path 



The route a packet takes from source to 
destination node. 



Path Cost 



The sum of the line costs along a path 
between two nodes. See line cost. 



Path Length 



The sum of the hops along a path between 
two nodes. 



Permanent Data Base 



Default 
entities 
memory (for 
established 
permanent d 
the NCP c 
can change 
CLEAR and 
not support 



nformation 
that is ke 

example, fi 
at networ 
ata base can 
ommands PURG 
the volatile 
SET commands 

a permanent 



about network 
pt in permanent 
les) . Generally 
k generation. A 

be changed with 
E and DEFINE; you 

data base with 
DECnet-10 does 

data base. 



Permanent Virtual Circuit (PVC) 

A virtual circuit always associated with 
the same remote DTE address. The 
software references a PVC by its logical 
channel number (LCN) . The public 
network vendor establishes the 
correspondence between a PVC and its 
LCN. 
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Physical Address 



Physical Connectivity 



Physical Link 



The unique address value associated with 
a given system on an Ethenet circuit. 
An Ethernet physical address is defined 
to be distinct from all other physical 
addresses on Ethernet. 

The condition of nodes being attached to 
each other by active lines. 

A communication path between two 
adjacent nodes. This can be a dial-up 
line, radio, satellite link, or a 
channel-to-channel connector such as a 
DTE 20. 



Port 



The resources required to manage a 
virtual circuit. 



PPSN 

Plural Entity 

Point-to-point 

Processed Event 



Public Packet Switching Network. 

A set of entities classified as known, 
active, or loop (nodes only), 

A circuit that connects two nodes, 
operating over a single line. 

An event after local processing in final 
form. 



Protocol 



Reachable Node 



Remote DTE 



A formal set of conventions or rules 
governing the format and relative timing 
of message exchange. 

A node to which the executor node's 
routing process believes it has a usable 
communication path. 

The DTE on the public network with which 
the local user in a DECnet network 
wishes to communicate. The remote DTE 
may give access to another network in 
addition to the DECnet network of the 
local user, and the public network with 
which the local user communicates. 



Remote Node 



A node in a network that is not your 
local node. 



Remote Task 
Remote User 



A task executing in a remote node. 

A user at the remote DTE with whom the 
local user communicates over a virtual 
circuit. 



Restricted State 



A node state where no new logical links 
from other nodes are allowed. 



Routing 



The network function that determines the 
path along which data travels to its 
destination. 



Routing Node 



A node that contains the full set of 
Routing modules, and can deliver, 
receive, and route through packets. 
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Server Task 



Service Password 



Service Slave Node 



Service State 



Shut State 



An alternate designation for a task that 
has declared itself willing to accept a 
network connection, usually to provide 
some system service. 

The password required to permit 
triggering of a node's bootstrap ROM. 

That mode where the processor is taken 
over and the adjacent, executor node is 
in control, typically for execution of a 
bootstrap program for downline loading 
or for upline dumping. 

A line state where such operations as 
downline load, upline dump, or line 
loopback are performed. This state 
allows direct access to the line by 
Network Management. 

A node state where existing logical 
links are undisturbed, but new ones are 
prevented . 



Singular Entity 



A specific entity; for example, a line, 
a logging sink type, a node, or a 
circuit. 



Sink 
Sink Node 



See logging sink, 

A node where logging sink types are 
located. 



Sink Type 



A particular final destination for 
logging events, either a file or a 
console. 



Source Node 



Source Task 



Specific Filter 



Status 



The node at which the request for a 
connection is initiated or from which a 
message is transmitted. 

The task in which the request for a 
connection is initiated or from which a 
message is transmitted. 

A filter that applies to a specific 
entity within an event class and type. 

Dynamic information relating to 
entities, such as their state. Status 
is a Network Management information 
type. Also, a message indicating 
whether or not an NCP command succeeded. 



Substate 



Summary 



An intermediate line state that appears 
as a tag on a line state display. 

An information type meaning the most 
useful information for an entity? the 
default if no information type is 
requested. 
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Switched Virtual Circuit (SVC) 



Target Node 



Terminal Server 



A temporary logical association between 
two DTEs connected to a PPSN, analogous 
to connection by a dial-up line. An SVC 
is set only when there is data to 
transmit; the SVC is cleared when the 
data transfer is complete. 

The node that receives a memory image 
during a downline load, generates an 
upline dump or loops back a test 
message. 

An Ethernet node that enables a number 
of terminals to communicate with 
multiple host nodes. Terminal servers 
are connected to an Ethernet cable. 
Terminals using the terminal server can 
only communicate with DECnet hosts on 
the Ethernet cable. 



Terminating Packet 
Topology 

Transit Packet 



A packet whose destination is this node. 

The. physical arrangement and 
relationship of interconnected nodes and 
lines in the network. A legal topology 
satisfies all DNA requirements. 

A packet arriving at this node from a 
source node and intended for another 
node. 



Tributary 



Unit 



A physical termination on a multipoint 
line that is not a control station. 
Part of the line identification for a 
multipoint line. 

Part of a line/circuit identification. 
Together with the controller, a unit 
forms a station. In the line 
identification KDP-2-0, "KDP" identifies 
the device (KMCll/DUPll) , "2" identifies 
the controller , and "0" identifies the 
unit. 



Unreachable Node 



Upline Dumping 



A node is unreachable when the path 
length to that node is longer than the 
maximum number of hops in the network. 

Transmitting a copy of a memory image 
over a line to a file at the host node. 



Virtual Call 



The process of establishing a virtual 
circuit between two DTEs. 



Virtual Circuit 



A logical path between the user process 
in a DECnet node and a cooperating 
process in a remote DTE. A virtual 
circuit is similar to a DECnet logical 
link. 
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Volatile Data Base 



The volatile, or temporary data base 
consists of dynamic values currently in 
memory. It can contain parameters such 
as status, line or node state, or 
characteristics, such as CPU type or 
timer values, that remain constant until 
cleared or reset. Volatile data base 
values are lost when the system shuts 
down. When the system is first brought 
up, data from the permanent data base, 
if any, is read into the volatile data 
base. The operator can change certain 
of these values with the SET NCP 
command. Changes made to the permanent 
data base with the DEFINE command are 
not reflected in the volatile data base 
until the system is brought up again, 
DECnet-10 does not support the permanent 
data base. 



X.3 



A CCITT recommendation that specifies 
the Packet Assembly/Disassembly (PAD) 
facility in a public data network. 



X.25 



A CCITT recommendation that specifies 
the interface between Data Terminal 
Equipment and Data Circuit-terminating 
Equipment for equipment operating in the 
packet mode on public data networks. 



X.29 



A CCITT recommendation that specifies 
procedures for the exchange of control 
information and user data between a 
packet-mode DTE and a packet 
Assembly/Disassembly (PAD) facility. 
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Access control, 4-5 

parameters, 6-6 
Accessing NCP commands, 4-5 
Adjacent node, 2-1 
Area entity, 7-15 

identification, 7-4 
Area routing, 2-9 
Areas, 2-9 

Bibliography, E-1 
Buffer size, 2-12 

setting, 3-34 
Buffers 

maximum number of, 3-35 



Cache, 2-11 

CANCEL QUEUE REQUEST command, 6-5 
CCITT recommendations, E-1 
Changing network data bases, 7-16, 

7-40 
CHKll output, 3-29 
Circuit, 2-1 

controlling state, 3-8 
entity, 7-7 
Circuit counters, B-4 
Circuit entity identification, 

7-3 
Circuit level loopback testing, 

3-28 
Circuits 

Ethernet, 1-9 
maximum number of, 3-35 
CLEAR CIRCUIT command, 7-41 

(X.25), 8-19 
CLEAR EXECUTOR command, 6-3 
CLEAR EXECUTOR example, 6-4 
CLEAR KNOWN CIRCUITS command, 

7-41 
(X.25) , 8-19 
CLEAR KNOWN LINES command, 7-41 

(X.25) , 8-19 
CLEAR KNOWN NODES command, 7-42 
CLEAR LINE command, 7-41 

(X.25), 8-19 
CLEAR LOGGING command, 7-41 
CLEAR MODULE X25-ACCESS command, 

8-20 
CLEAR MODULE X25-ACCESS example, 

8-20 
CLEAR MODULE X25-PROTOCOL command, 

8-20 
CLEAR MODULE X25-PROTOCOL example, 

8-20 
CLEAR MODULE X25-SERVER command, 

8-20 
CLEAR MODULE X25-SERVER example, 

8-20 
CLEAR NODE command, 7-42 



Command files 

manual startup with, 3-4 

Command input, 4-6 

Command node, 2-1 

in downline load, 3-13 

Command output response, 4-6 

Commands 

CANCEL QUEUE REQUEST, 6-5 

CLEAR CIRCUIT, 7-41 

CLEAR EXECUTOR, 6-3 

CLEAR KNOWN CIRCUITS, 7-41 

CLEAR KNOWN LINES, 7-41 

CLEAR KNOWN NODES, 7-42 

CLEAR LINE, 7-41 

CLEAR LOGGING, 7-41 

CLEAR MODULE X25-ACCESS, 8-20 

CLEAR MODULE X25-PROTOCOL, 8-2( 

CLEAR MODULE X25-SERVER, 8-20 

CLEAR NODE, 7-42 

DEFINE EXECUTOR, 6-3 

DUMP, 7-47 

editing, 4-3 

ENTER, 5-1 

EXIT, 5-1 

for network monitoring, 3-9 

HELP, 6-8 

LOAD, 7-48 

LOOP, 7-51 

LOOP CIRCUIT, 3-24 

LOOP LINE, 3-24 

LOOP NODE, 3-24 

multiple lines, 4-4 

NCP processed by NML, 7-1 

OPR/NCP, 5-1 

PURGE EXECUTOR, 6-4 

PUSH, 5-1 

RETURN, 5-1 

SET CIRCUIT, 7-18 

SET CIRCUIT (X.25), 8-2 

SET CIRCUIT ALL, 7-17 

SET EXECUTOR, 6-1, 7-29 

SET EXECUTOR (X.25), 8-15 

SET KNOWN CIRCUITS, 7-22 

SET KNOWN CIRCUITS (X.25), 8-2 

SET KNOWN NODES, 7-39 

SET KNOWN NODES (X.25), 8-15 

SET LINE, 7-23 

SET LINE (X.25) , 8-15 

SET LINE ALL, 7-17 

SET LOGGING, 7-39 

SET MODULE CONFIGURATOR, 7-25 

SET MODULE CONSOLE, 7-26 

SET MODULE LOADER, 7-27 

SET MODULE LOOPER, 7-27 

SET MODULE X25-ACCESS, 8-5 

SET MODULE X25-PROTOCOL, 8-6 

SET MODULE X25-SERVER, 8-10 

SET NODE, 7-29 

SET NODE (X.25) , 8-15 
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Commands ( Cont . ) 

SET NODE ALL, 7-17 

SET NODE CIRCUIT, 7-27 

SET NODE NAME, 7-28 

SHOW, 7-44 

SHOW MODULE (X.25), 8-16 

SHOW QUEUE, 6-5 

TAKE, 5-1 

TELL prefix, 6-6 

TRIGGER, 7-53 

typing, 4-3 

using comments, 4-4 

WAIT, 5-1 

X.25-specif ic, 8-2 

X29SRV management, D-3 

ZERO, 7-54 

ZERO (X.25), 8-19 
Comments 

in commands, 4-4 
Communications server 

downline loading, 3-21 
Compatibility 

Phase Ill/Phase IV, 2-13 
CONFIGURATOR module, 7-14 
Connecting remote console, 3-24 
CONSOLE module, 7-15 
Controlling node, circuit, DTE, 

and line state, 3-8 
Controlling the network, 7-47 
Counters 

circuit, B-4 

DECnet-10 specific, B-1 

Line, B-6 

node, B-9 

summary, B-1 

X.25 Protocol module, B-12 

X.25 server module, B-13 

X.25 specific, B-2 

Data link control, 3-34 
Data Link Layer (DNA) , 1-8 
Data Link Layer events, C-20 
Data Link Watcher, 1-6 
Data links, 2-1 
DECnet counter summary, B-1 
DECnet implementations, 1-10 
DECnet line devices, F-1 
DECnet restart procedures, 3-6 
DECnet startup procedures, 3-1 
DECnet-10 

capabilities, 1-10 

extensions, 7-2 

hardware, 1-9 

host services, 3-12 

implementation, 7-2 

Version 4.0 implementation, 1-8 
DECnet-10 specific counters, B-1 
DEFINE EXECUTOR command, 6-3 
Designated router (Ethernet) , 

2-11 
DN20 

downline loading, 3-21 

events, 7-13 



DN20 (Cont.) 

upline dump, 3-23 
DN20 commmunications front end, 

1-8 
DN20 coummunications front end 

see MCB 
DNA 

Data Link Layer, 1-8 

End Communication Layer, 1-7 

layered structure of, 1-3 

major features of, 1-3 

Network Application Layer, 1-7 

Network Management Layer, 1-5 

Physical Link Layer, 1-8 

Routing Layer, 1-7 

Session Control Layer, 1-7 

User Layer, 1-4 
DNA model, 1-1 
Downline loading, 3-13 

bootstraps, 3-16 

communications server, 3-21 

DN20, 3-21 

operator initiated, 3-14 

requirements, 3-15 

target initiated, 3-14 
Downline loading parameters, 3-18 
DTE 

controlling state, 3-8 
Dump 

upline, 3-22 
Dump assistance multicast address, 

3-22 
DUMP command, 7-47 
DUMP example, 7-47 

Editing commands, 4-3 

End Communication Layer (DNA) , 

1-7 
End Communication Layer events, 

C-14 
End node caching, 2-11 
End nodes, 2-8 

see Ethernet nodes 
ENTER command, 5-1 
Entities, 7-2 

area, 7-15 

area identification, 7-4 

circuit, 7-7 

circuit identification, 7-3 

line, 7-7 

line identification, 7-3 

logging, 7-10 

logging identification, 7-4 

Maintenance module, 7-14 

MODULE (X.25), 8-1 

module identification, 7-5 

node, 7-5 

node identification, 7-4 
Entity, 2-6 

Entity identification, 7-3 
Error messages 

NCP, C-4 
ERROR. SYS file, 3-10 
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Ethernet 

designated router, 2-11 

end node caching, 2-11 
Ethernet address 

format of, 3-31 
Ethernet circuit, 1-9 
Ethernet multicast address, 3-32 
Ethernet nodes, 2-8 
Ethernet physical address, 3-32 
Ethernet routers, 2-11 
Event 

processor, 1-6 

receiver, 1-6 

recorder, 1-6 

transmitter, 1-6 
Event classes, C-11 
Event messages, C-11 
Events, 7-11 

data link layer, C-20 

DN20, 7-13 

end communications layer, C-14 

loggings at remote node, 7-14 

Network Management Layer, C-12 

Routing layer, C-15 

selecting, 7-12 

session control layer, C-14 
Examples 

CLEAR EXECUTOR command, 6-4 

CLEAR MODULE X25-ACCESS, 8-20 

CLEAR MODULE X25-PROTOCOL, 8-20 

CLEAR MODULE X25-SERVER, 8-20 

DUMP, 7-47 

LOOP, 7-52 

LOOP LINE, 3-27 

LOOP NODE, 3-25 

OPR/NCP commands, 5-1 

request for characteristics, 
4-7 

request for status of known 
circuits, 4-7, 4-8 

SET CIRCUIT, 7-22 

SET EXECUTOR NODE, 6-2 

SET KNOWN CIRCUITS, 7-23 

SET KNOWN NODES, 7-39 

SET LINE command, 7-25 

SET LOGGING, 7-40 

SET MODULE CONFIGURATOR, 7-26 

SET MODULE CONSOLE, 7-26 

SET MODULE LOADER, 7-27 

SET MODULE X25-ACCESS, 8-6 

SET MODULE X25-PROTOCOL, 8-10 

SET MODULE X25-SERVER, 8-12 

SET NODE, 7-38 

SET NODE CIRCUIT, 7-27 

SET NODE NAME, 7-28 

SHOW, 7-45 

SHOW MODULE (X.25), 8-16 

SHOW QUEUE command, 6-5 

SPEAR program, 3-11 

TELL prefix, 6-7 

TRIGGER, 7-54 

ZERO, 7-54 

ZERO (X.25) , 8-19 



Executor 

specifying the, 4-8 
Executor node, 2-1 

in downline load, 3-13 
EXIT command, 5-1 

FAL program, 3-35 
File Access Listener 

see FAL program 
File specifications 

in NCP commands, 4-9 

Gateway Access Library, 2-4 
Gateway Access Protocol, 2-4 
Generic format of NCP/NML 

commands, 7-16 
Glossary, G-1 

Hardware 

KL10, 1-9 

KS10, 1-9 
Help 

from NCP, 4-4 
HELP command, 6-8 
Host node, 2-1 
Hosting, 3-12 

Informational messages, C-2 
INITIA program, 3-1 

KL10 hardware, 1-9 
KS10 hardware, 1-9 

Level 1 routers, 2-9, 2-10 
Level 2 routers, 2-9, 2-10 
Line 

controlling state, 3-8 

entity, 7-7 
Line counters, B-6 
Line devices 

DECnet, F-1 
Line entity identification, 7-3 
LOAD command, 7-48 
LOADER module, 7-15 
Loaders 

primary, 3-15 

secondary, 3-15 

tertiary, 3-15 
Loading 

downline, 3-13 
Local node, 2-1 
Logging 

entity, 7-10 

event identification, 7-11 

events at remote nodes, 7-14 

parameters, 7-13 
Logging entity identification, 

7-4 
Logical link, 2-1 
LOOP CIRCUIT command, 3-24 
LOOP command, 7-51 
LOOP example, 7-52 
LOOP LINE command, 3-24 
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LOOP LINE example, 3-27 
Loop Message Generator, 1-7 
LOOP NODE command, 3-24 
LOOP NODE examples, 3-25 
Loopback Mirror, 1-7 
Loopback tests, 3-24 
LOOPER module, 7-15 

Maintenance Module entity, 7-14 
Managing X29SRV, D-1 
Manual startup 

with command files, 3-4 
Manual startup of MCB, 3-3 
Maximum address parameters, 3-30 
MCB 

manual startup of, 3-3 
MCB software, 1-9 
Messages 

events, C-11 

informational, C-2 

NCP command response, C-3 

NCP error, C-4 

network related, C-1 

OPR/NCP syntax, C-1 

status, C-4 
MODULE entity (X.25), 8-1 
Module entity identification, 7-5 
MODULE X25-ACCESS, 8-1 
MODULE X25-PROTOCOL, 8-2 
MODULE X25-SERVER, 8-2 
Monitoring network activity, 3-9 
Monitoring node activity, 7-54 
Monitoring the network, 7-43 
Multicast address 

ethernet, 3-32 

looping to, 3-28 
Multiple line commands, 4-4 
Multiple-area network, 2-9 

NCP, 4-1 

accessing commands, 4-5 

features, 4-3 

File specifications, 4-9 

functions, 4-2 

getting help, 4-4 

restricting commands, 4-5 
NCP command keywords 

overview, 1-11 
NCP command response messages, 

C-3 
NCP commands 

process by OPR, 5-1 

processed by NML, 7-1 

processed internally by NCP NML, 
6-1 
NCP error messages, C-4 
NCP/NML commands 

generic format, 7-16 
Network 

monitoring, 7-43 

testing, 3-24 
Network Application Layer (DNA) , 
1-7 



Network architecture, 1-1 
Network Control Program, 4-1 
Network data bases 

changing, 7-16 
Network Management Layer (DNA) , 

1-5 
Network Management Layer Events, 

C-12 
Network related messages, C-1 
Network Remote Terminal Protocol, 

2-4 
Networks 

controlling, 7-47 

Multiple-area, 2-9 

Public packet switching, 8-1 

single-area, 2-9 
NIA20, 1-9 
NICE receiver, 1-6 
NICE return codes, C-4 
NML 

restart procedures, 3-6 
NML concepts, 7-2 
Node 

controlling state, 3-8 
Node addresses 

removing, 3-31 
Node counters, B~9 
Node entity, 7-5 
Node entity identification, 7-4 
Node identification, 3-29 
Node names 

removing, 3-31 
Nodes, 2-1 

adjacent, 2-1 

command, 2-1 

Ethernet, 2-8 

executor, 2-1 

host, 2-1 

local, 2-1 

nonrouting, 2-8 

Phase II, 2-13 

Phase III, 2-13 

Phase IV, 2-13 

remote, 2-1 

routing, 2-8 

subordinate, 3-22 

target, 2-1, 3-13 

X.25, 2-2 
nodes 

command, 3-13 

executor, 3-13 
Nonrouting nodes, 2-8 
NRT Server, 2-4 

Operator 

functions, 2-14 
responsibilities, 2-14 
Operator command language OPR, 

1-6 
Operator initiated downline 

loading, 3-14 
OPR/NCP command syntax messages, 
C-1 
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OPR/NCP commands 

examples, 5-1 
ORION process 

restart procedures for, 3-6 
ORION program, 3-1 

Packet delivery 

and congestion, 2-12 
Packet Switching Interface, 3-1 
PAD parameter values, D-11 
Phase II nodes, 2-13 
Phase III nodes, 2-13 
Phase Ill/Phase IV compatibility, 

2-13 
Phase IV compatibility, 1-11 
Phase IV nodes, 2-13 
Physical address 
ethernet, 3-32 
Physical link, 2-1 
Physical Link Layer (DNA) , 1-8 
PPSN, 2-2 

Primary loader, 3-15 
PSI Gateway, 2-2 
PSI restart procedures, 3-6 
PSI software option, 1-9 
PSITSB restart procedure, 3-7 
Public Packet Switching Network, 

2-2 
Public Packet Switching Networks, 

8-1 
PURGE EXECUTOR command, 6-4 
PUSH command, 5-1 

Remote console 

connecting, 3-24 
Remote file access, 3-35 
Remote node, 2-1 

looping to, 3-28 
Remote nodes 

logging events at, 7-14 
Removing node addresses, 3-31 
Removing node names, 3-31 
Restart procedures, 3-6 

for NML, 3-6 

for ORION process, 3-6 

for PSITSB, 3-7 

for X29SRV, 3-7 
Restricting NCP commands, 4-5 
Restrictions 

topological, 2-13 
RETURN command, 5-1 
RMTCON facility, 3-24 
Routers 

designated, 2-11 

Ethernet, 2-11 

level 1, 2-9, 2-10 

level 2, 2-9, 2-10 
Routing 

area, 2-9 

level 1, 2-9 

level 2, 2-9 
Routing algorithm, 2-12 
Routing concepts, 2-6 



Routing Layer (DNA) , 1-7 
Routing Layer events, C-15 
Routing nodes, 2-8 

Secondary loader, 3-15 
Secondary loader files, 3-19 
Service circuit identification, 

3-20 
Service device identification, 

3-20 
Service passwords, 3-20 
Session Control Layer (DNA) , 1-7 
Session Control Layer Events, 

C-14 
SET CIRCUIT ALL command, 7-17 
SET CIRCUIT command, 7-18 

(X.25) , 8-2 
SET CIRCUIT example, 7-22 
SET EXECUTOR command, 6-1, 7-29 

(X.25), 8-15 
SET EXECUTOR NODE examples, 6-2 
SET KNOWN CIRCUITS command, 7-22 

(X.25), 8-2 
SET KNOWN CIRCUITS example, 7-23 
SET KNOWN NODES command, 7-39 

(X.25), 8-15 
SET KNOWN NODES example, 7-39 
SET LINE ALL command, 7-17 
SET LINE command, 7-23 

(X.25) , 8-15 
SET LINE example, 7-25 
SET LOGGING command, 7-39 
SET LOGGING example, 7-40 
SET MODULE CONFIGURATOR command, 

7-25 
SET MODULE CONFIGURATOR example, 

7-26 
SET MODULE CONSOLE command, 7-26 
SET MODULE CONSOLE example, 7-26 
SET MODULE LOADER command, 7-27 
SET MODULE LOADER example, 7-27 
SET MODULE LOOPER command, 7-27 
SET MODULE X25-ACCESS command, 

8-5 
SET MODULE X25-ACCESS example, 

8-6 
SET MODULE X25-PROTOCOL command, 

8-6 
SET MODULE X25-PROTOCOL example, 

8-10 
SET MODULE X25-SERVER command, 

8-10 
SET MODULE X25-SERVER example, 

8-12 
SET NODE ALL command, 7-17 
SET NODE CIRCUIT command, 7-27 
SET NODE CIRCUIT example, 7-27 
SET NODE command, 7-29 

(X.25), 8-15 
SET NODE example, 7-38 
SET NODE NAME command, 7-28 
SET NODE NAME example, 7-28 
Setting buffer size, 3-34 
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SHOW command, 7-44 

SHOW example, 7-45 

SHOW MODULE (X.25) examples, 8-16 

SHOW MODULE command 

(X.25) , 8-16 
SHOW QUEUE command, 6-5 
SHOW QUEUE example, 6-5 
Single-area network, 2-9 
SPEAR program, 3-10 

example, 3-11 
Specifying the executor, 4-8 
Startup procedure 

automatic DECnet, 3-1 
Startup procedures 

DECnet, 3-1 

manual of MCB, 3-3 

manual with command files, 3-4 
Status messages, C-4 
Subordinate node, 3-22 
System manager 

functions, 2-15 

responsibilities, 2-15 

TAKE command, 5-1 

Target initiated downline loading, 

3-14 
Target node, 2-1 

in downline load, 3-13 
TELL prefix, 6-6 
TELL prefix example, 6-7 
Tertiary loader, 3-15 
Tertiary loader files, 3-19 
Testing 

circuit level loopback, 3-28 
Testing the network, 3-24 



Topological restrictions, 2-13 
TRIGGER command, 7-53 
TRIGGER example, 7-54 
Typing commands, 4-3 

Upline Dumping 

requirements, 3-23 
Upline dumping, 3-22 

DN20, 3-23 
User Layer (DNA) , 1-4 
Using nodes addresses, 3-31 
Using nodes names, 3-31 

WAIT command, 5-1 

X.25 facility, 8-1 

X.25 network, 2-2 

X.25 node, 2-2 

X.25 protocol module counters, 

B-12 
X.25 server module counters, 8-13 
X,25 Specific counters, B-2 
X. 25-specif ic commands, 8-2 
X,29 configuration file, D-1 
X.29 Server, 2-4 
X29SRV 

managing, D-1 

restart procedure, 3-7 
X29SRV management commands, D-3 
X29SRV.INI file, D-2 

ZERO (X.25) examples, 8-19 
ZERO command, 7-54 

(X.25), 8-19 
ZERO example, 7-54 
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